JP2001134534A - 認証代行方法、認証代行サービスシステム、認証代行サーバ装置及びクライアント装置 - Google Patents

Abstract

(57)【要約】 【課題】 クライアント認証を代行する認証代行サーバ
に情報が漏洩することを防止する。 【解決手段】 認証代行サーバＳは、サービス提供時、
所望のサービスに対応したサービスプロバイダＳＰ−
Ａ，ＳＰ−Ｂの暗号用公開鍵をクライアントＣへ配送
し、クライアントＣから受け取った暗号化された情報を
プロバイダＳＰ−Ａ，ＳＰ−Ｂへ転送する。クライアン
トＣは、プロバイダＳＰ−Ａ，ＳＰ−Ｂへ送信すべき情
報を認証代行サーバＳから受け取った暗号用公開鍵を用
いて暗号化し、この暗号化された情報を認証代行サーバ
Ｓへ送信する。プロバイダＳＰ−Ａ，ＳＰ−Ｂは、認証
代行サーバＳから受け取った暗号化された情報を暗号用
秘密鍵を用いて復号化する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、サービスプロバイ
ダ装置とクライアント装置との間に設けられた認証代行
サーバ装置がクライアント装置に代わってサービスプロ
バイダ装置から認証を受ける認証代行方法、認証代行サ
ービスシステム、認証代行サーバ装置及びクライアント
装置に関するものである。

【０００２】

【従来の技術】従来、ネットワークによるサービス提供
においては、秘密情報を用いてクライアント認証を行う
ことが一般的に行われている。ここで、秘密情報とは、
例えばパスワード、ＲＳＡ（Rivest、Shamir and Adle
man ）などの公開鍵暗号方式における秘密鍵、ＤＥＳ
（Data Encryption Standard）などの共有鍵方式の共有
鍵を指す。クライアント認証を行う場合、一般的には、
異なるサービス提供者に対しては、秘密情報は異なるも
のが使われる。

【０００３】例えば、図１３に示すように、あるクライ
アント装置（以下、クライアントと略する）Ｃがサービ
スプロバイダ装置（以下、サービスプロバイダと略す
る）ＳＰ−Ａによって提供されるサービスＡとサービス
プロバイダＳＰ−Ｂによって提供されるサービスＢにそ
れぞれアクセスする際には、それぞれ別の秘密情報Ｓｋ
Ｕ−ＡとＳｋＵ−Ｂを使用してクライアント認証を受け
る必要がある。図１３において、ＣｅｒｔＵ−Ａ，Ｃｅ
ｒｔＵ−Ｂは、それぞれ秘密情報ＳｋＵ−Ａ，ＳｋＵ−
Ｂに対応した証明書である。この証明書は方式によって
は不要である。例えば、公開鍵暗号方式では、秘密情報
ＳｋＵは秘密鍵、ＣｅｒｔＵは公開鍵証明書となる。な
お、ここでの「サービスプロバイダ」とは、現実の世界
におけるサービス提供者（例えば企業）を必ずしも意味
しない。つまり、現実の世界におけるサービス提供者が
同じであっても、「サービスプロバイダが異なる」場合
が有り得る。例えば、ある銀行の残高照会サービスと投
資信託申込サービスは別のサービスプロバイダによって
提供されるサービスと考える。

【０００４】異なるサービスプロバイダ間でクライアン
ト情報の共有に同意すれば、秘密情報を同一にすること
は可能である。例えば、図１３に示した例で言えば、サ
ービスプロバイダＳＰ−ＡとＳＰ−Ｂが合意すれば、サ
ービスプロバイダＳＰ−Ａに対する秘密情報ＳｋＵ−Ａ
を用いてサービスＢの提供を受けることは可能である
（図１４）。特に、前述の例で同一銀行の２つのサービ
スであれば、現実の世界ではサービスプロバイダＳＰ−
ＡとＳＰ−Ｂは同一であるため、合意は比較的容易であ
る。しかし、存在するあらゆるサービスプロバイダ間で
合意することは困難であり現実的ではない。クライアン
トＣに秘密情報を発行する際の方針の違いや、秘密情報
の強度の違い、サービスの要求セキュリティの違いなど
により、合意が難しいケースは数多く存在する。つま
り、クライアント認証に関する各サービスプロバイダの
方針が異なるため、合意が難しい場合が数多く存在す
る。

【０００５】クライアント認証に関する方針がある程度
一致する場合には、認証局を階層的に構成することによ
り、同一の秘密情報により認証を受けることが可能な場
合もある。例えば、図１５に示すように、秘密情報に対
する証明書を認証局ＣＡ−ＡあるいはＣＡ−Ｂが発行
し、その認証局ＣＡ−Ａ，ＣＡ−Ｂの秘密情報に対して
さらに上位の認証局ＣＡ−Ｒが証明書を発行する、とい
うような形で認証ツリーを構成する。そして、サービス
プロバイダＳＰ−Ａの秘密情報に対する認証ツリーとサ
ービスプロバイダＳＰ−Ｂの秘密情報に対する認証ツリ
ーが上位において交点を持っていれば、秘密情報ＳｋＵ
−ＡによってサービスプロバイダＳＰ−Ｂがサービスを
提供できる場合がある。図１５において、ＣＡ−Ａ，Ｃ
Ａ−ＢはサービスプロバイダＳＰ−Ａのサービスを受け
るための認証局、ＣＡ−Ｒは認証局ＣＡ−Ａ，ＣＡ−Ｂ
の上位の認証局である。なお、ＣＡ−Ａ，ＣＡ−ＢとＣ
Ａ−Ｒとの中間、あるいはＣＡ−Ｒの上位に他の認証局
が介在する場合もある。サービスプロバイダＳＰ−Ｂ
は、自クライアントの認証局であるＣＡ−Ｂの上位認証
局ＣＡ−Ｒが認証しているＣＡ−Ａの発行した証明書に
より、秘密情報ＳｋＵ−Ａを用いたクライアント認証を
認める。

【０００６】図１５の場合においても、あらゆるサービ
スの認証ツリーに交点を持たせることは困難であり、ま
た、交点があったとしても、セキュリティの方針の違い
などにより必ずしもサービス提供が可能とは限らない。
つまり、クライアントＣが誰であるか分かったとして
も、サービスプロバイダの方針によってはサービス提供
を拒否する場合があり得る。したがって、「クライアン
ト認証が必要な複数のサービスを受ける場合、クライア
ントは、各サービスに対応した複数の秘密情報を管理す
る必要がある」、ということが一般的には言える。ここ
では、同一の秘密情報により認証を受けることができる
場合を「サービスの認証体系が同一」と呼ぶこととす
る。反対に、同一の秘密情報により認証を受けることが
できない場合を「サービスの認証体系が異なる」と呼ぶ
こととする。

【０００７】一般に、秘密情報の管理機能、及び秘密情
報を用いてクライアント認証を受ける機能をクライアン
トＣに実装するコストは大きく、複数のサービスに対し
て複数の秘密情報を用いる場合には更に大きくなる。秘
密情報の管理に関して言えば、秘密情報を遺失した場合
にはサービスを受けられなくなってしまうという問題が
生じ、秘密情報が漏洩した場合には他のクライアントが
自クライアントになりすます危険があるため、遺失防止
機能及び漏洩防止機能の実装のコストが大きくなる。複
数の秘密情報の管理が必要な場合には、管理そのものの
コストが大きくなる上に、管理形態によっては、どれか
一つの秘密情報が遺失・漏洩すると他の秘密情報も再発
行しなければならない場合があり、再発行コストが大き
くなる。

【０００８】秘密情報を用いたクライアント認証機能に
関しては、例えば公開鍵暗号方式を用いる場合、秘密鍵
の管理以外に、対応する公開鍵証明書の保管機能、公開
鍵証明書のサービスプロバイダへの送信機能、秘密情報
（公開鍵暗号方式における鍵ペアなど）の生成機能、認
証局への秘密情報の登録機能、公開鍵証明書取得機能な
どがクライアントＣに必要になる。クライアントＣに簡
易な端末、例えばセットトップボックスなどを想定した
場合、管理する秘密情報が少なかったとしてもこれら全
ての機能を実装するコストは大きいが、秘密情報が増え
るとさらに大きくなる。こうしたことから、クライアン
トＣで管理する秘密情報の数はできるだけ少なくしたい
という、クライアント管理者の要求が存在する。

【０００９】このようなクライアント管理者の要求、す
なわち認証体系が異なる複数のサービスを受ける場合
に、クライアント管理者が管理する秘密情報を少なくし
たいということを解決する従来技術としては以下のよう
な３つがある。 従来技術１：認証局同士の相互認証。 従来技術２：認証代行サーバヘ秘密情報を預ける形態で
の認証処理の委託。 従来技術３：認証代行サーバ自身の秘密情報を使う形態
での認証処理の委託。

【００１０】従来技術１は、図１６に示すように、認証
ツリーに交点を持たない場合や、持っていたとしても当
該サービス提供可能なレベルで各ＳＰの認証に関する方
針が一致していなかった場合に、認証局ＣＡ−Ａ０，Ｃ
Ａ−Ｂ０同士の相互認証書を確認することで、同一の秘
密情報により認証を受けることができるようにする方式
である。図１６において、ＣＡ−Ａ１，ＣＡ−Ａ２，Ｃ
Ａ−Ｂ１，ＣＡ−Ｂ２は認証局、ＣＡ−Ａ０は認証局Ｃ
Ａ−Ａ１，ＣＡ−Ａ２の上位の認証局、ＣＡ−Ｂ０は認
証局ＣＡ−Ｂ１，ＣＡ−Ｂ２の上位の認証局である。サ
ービスプロバイダＳＰ−Ｂは、自クライアントの認証局
（例えばＣＡ−Ｂ１）の上位認証局ＣＡ−Ｂ０と他の上
位認証局ＣＡ−Ａ０との間で相互認証書が存在すること
により、秘密情報ＳｋＵ−Ａを用いたクライアント認証
を認める。この従来技術１は有望な方式の一つではあ
る。しかし、サービスプロバイダや認証局に大きな機能
追加が必要であり、また相互認証書を発行するというこ
とは結局各サービスプロバイダの合意形成が必要である
ことから、適用範囲が限られる。したがって、本発明で
は考慮の対象としない。

【００１１】従来技術２は、図１７に示すように、クラ
イアントＣが所属する一つの認証体系内にその他の認証
体系での秘密情報、証明書、ＣＲＬ（失効証明書リス
ト）などを管理する認証代行サーバＳを設け、クライア
ント認証が必要なサービスについては認証代行サーバＳ
と各サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ間で認証を
行う方式である。図１７において、ＳｋＵ−Ｐは認証代
行サーバＳとクライアントＣ間の認証に用いるための秘
密情報である。この秘密情報ＳｋＵ−Ｐについては、ク
ライアント管理者が記憶して、クライアントＣ自体では
管理しない場合もある。また、ＣｅｒｔＵ−Ｐは、秘密
情報ＳｋＵ−Ｐに対応した証明書である。この証明書は
方式によっては不要である。例えば、公開鍵暗号方式で
は、秘密情報ＳｋＵ−Ｐは秘密鍵、ＣｅｒｔＵ−Ｐは公
開鍵証明書となる。

【００１２】従来技術２は、従来技術１と比べて認証
局、サービスプロバイダ側には変更が少ないという利点
がある。認証局及びサービスプロバイダ側から見ると、
認証代行サーバＳは意識されず、クライアントＣとして
認証される。例えば、インターネット上のクレジット決
済や銀行口座決済を実現する方式であるＳＥＴ（Secure
Electronic Transaction ）やＳＥＣＥ（Secure Electr
onic Commerce Environment）においては利用者認証が
必要となり、複数のクレジット会社及び銀行からサービ
スを受けるために、それぞれ秘密情報を保持する必要が
あるが、この秘密情報をサーバウォレットと呼ばれる認
証代行サーバに預ける方式が提案されており、一部製品
化されている。

【００１３】従来技術３は、図１８に示すように、サー
ビスプロバイダＳＰ−Ａ，ＳＰ−Ｂからクライアント認
証を受ける際に、各クライアントＣの秘密情報を用いる
のではなく、認証代行サーバＳ自身の秘密情報ＳｋＰを
用いる方式である。図１８において、ＣｅｒｔＰは秘密
情報ＳｋＰに対応した証明書である。つまり、サービス
プロバイダ側からは、認証代行サーバＳがサービスを受
けているように見える。この従来技術３では、従来技術
２と同様に、各クライアントＣは各サービスに対応する
秘密情報を管理する必要はなく、また認証代行サーバＳ
においても、自身の秘密情報のみを管理すればよいこと
になる。

【００１４】

【発明が解決しようとする課題】しかしながら、以上の
従来技術２、従来技術３には、以下のような３つの問題
点があった。 問題点１：クライアントＣとサービスプロバイダＳＰ−
Ａ，ＳＰ−Ｂ間でやりとりする全ての情報が認証代行サ
ーバＳに漏洩する。クライアントＣにとって認証代行サ
ーバＳは信頼できる主体であるが、サービスによっては
サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂとやりとりする
情報を秘匿したい場合がある。仮に、クライアントＣと
認証代行サーバＳの間、認証代行サーバＳとサービスプ
ロバイダＳＰ−Ａ，ＳＰ−Ｂの間をそれぞれ暗号化して
いたとしても、認証代行サーバＳ内では情報が復号化さ
れるため、情報が漏洩する恐れがある。なお、この問題
点１は、従来技術２、従来技術３の両者に共通するもの
である。

【００１５】問題点２：認証代行サーバＳがクライアン
トＣになりすました場合、サービスプロバイダＳＰ−
Ａ，ＳＰ−Ｂ側では確認できない。従来技術２におい
て、認証代行サーバＳは、クライアント秘密情報を保持
しているため、クライアントＣになりすますことが可能
である。認証代行サーバＳは、一般には利用者からもサ
ービスプロバイダＳＰ−Ａ，ＳＰ−Ｂからも信頼できる
主体であるが、例えば、万が一、認証代行サーバＳのシ
ステム運用者などが不正を働いた場合や、クライアント
利用者がサービスの提供を受けたことを否認した場合な
どを想定すると、サービスプロバイダＳＰ−Ａ，ＳＰ−
Ｂ側で直接クライアントを認証できる手段を用意してお
くことが望ましい。もちろん、認証代行サーバＳが存在
することの利点を考えると、その際の認証手段は認証代
行サーバＳが存在しない場合に比べて簡易である必要が
ある。

【００１６】問題点３：クライアントＣとサービスプロ
バイダＳＰ−Ａ，ＳＰ−Ｂ間でサービスを提供する責
任、及びサービス対価を回収する責任が認証代行サーバ
Ｓに生じやすい。従来技術３において、サービスプロバ
イダＳＰ−Ａ，ＳＰ−Ｂは、認証代行サーバＳ自身の秘
密情報によりクライアントを認証しサービス提供を行
う。つまり、サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ
は、認証代行サーバＳを意識してサービスを提供してい
るのであり、そのサービスをクライアントＣに届ける責
任と、サービス対価をクライアントＣから徴収する責任
が認証代行サーバＳに生じやすい（実際に生じるかどう
かは当事者間の契約や法体系による）。その場合、責任
が大きくなればなるほど、認証代行サーバＳを運営でき
る主体が限られてしまうことになる。本発明は、上記課
題を解決するためになされたもので、認証に関するクラ
イアントの負担を認証代行サーバにより解決しつつ、前
記問題点１、問題点２及び問題点３を解消することがで
きる認証代行方法、認証代行サービスシステム、認証代
行サーバ装置及びクライアント装置を提供することを目
的とする。

【００１７】

【課題を解決するための手段】本発明の認証代行方法
は、サービスを提供するサービスプロバイダ装置とサー
ビス提供を受けるクライアント装置との間に設けられた
認証代行サーバ装置がクライアント装置に代わってサー
ビスプロバイダ装置から認証を受けるようにしたもので
ある。そして、本発明の認証代行方法は、サービス提供
時、所望のサービスに対応したサービスプロバイダ装置
の暗号用公開鍵を認証代行サーバ装置からクライアント
装置へ配送する手順と、クライアント装置においてサー
ビスプロバイダ装置へ送信すべき情報を認証代行サーバ
装置から受け取った暗号用公開鍵を用いて暗号化し、こ
の暗号化された情報を認証代行サーバ装置へ送信する手
順と、クライアント装置から受け取った暗号化された情
報を認証代行サーバ装置からサービスプロバイダ装置へ
転送する手順と、サービスプロバイダ装置において認証
代行サーバ装置から受け取った暗号化された情報を暗号
用秘密鍵を用いて復号化する手順とを有するものであ
る。また、本発明の認証代行方法は、サービス提供時、
所望のサービスに対応したサービスプロバイダ装置に対
して、クライアント装置の暗号用公開鍵を認証代行サー
バ装置から配送する手順と、サービスプロバイダ装置に
おいてクライアント装置へ送信すべき情報を認証代行サ
ーバ装置から受け取った暗号用公開鍵を用いて暗号化
し、この暗号化された情報を認証代行サーバ装置へ送信
する手順と、サービスプロバイダ装置から受け取った暗
号化された情報を認証代行サーバ装置からクライアント
装置へ転送する手順と、クライアント装置において認証
代行サーバ装置から受け取った暗号化された情報を暗号
用秘密鍵を用いて復号化する手順とを有するものであ
る。

【００１８】また、本発明の認証代行方法は、サービス
提供時、所望のサービスに対応したサービスプロバイダ
装置の暗号用公開鍵を認証代行サーバ装置からクライア
ント装置へ配送する手順と、クライアント装置において
サービスプロバイダ装置との間の暗号通信用セッション
キーあるいはこのセッションキーの元となるデータを生
成し、セッションキーあるいはデータを認証代行サーバ
装置から受け取った暗号用公開鍵を用いて暗号化し、こ
の暗号化された情報を認証代行サーバ装置へ送信する手
順と、クライアント装置から受け取った暗号化された情
報を認証代行サーバ装置からサービスプロバイダ装置へ
転送する手順と、サービスプロバイダ装置において認証
代行サーバ装置から受け取った暗号化された情報を暗号
用秘密鍵を用いて復号化してセッションキーを取得し、
あるいは暗号用秘密鍵を用いた復号化によりデータを取
得して、このデータからセッションキーを生成する手順
と、クライアント装置あるいはサービスプロバイダ装置
において送信すべき情報をセッションキーを用いて暗号
化し、この暗号化された情報を認証代行サーバ装置へ送
信する手順と、セッションキーを用いて暗号化された情
報を認証代行サーバ装置からサービスプロバイダ装置あ
るいはクライアント装置へ転送する手順と、セッション
キーを用いて暗号化された情報をサービスプロバイダ装
置あるいはクライアント装置において自身が有するセッ
ションキーを用いて復号化する手順とを有するものであ
る。

【００１９】また、本発明の認証代行方法の１構成例と
して、暗号用公開鍵を認証代行サーバ装置からクライア
ント装置へ配送する際に、暗号用公開鍵と共に暗号用公
開鍵証明書を配送する手順と、クライアント装置におい
て暗号用公開鍵を用いた暗号化を行う前に、認証代行サ
ーバ装置から受け取った暗号用公開鍵証明書を基に暗号
用公開鍵を検証する手順とを有するものである。また、
本発明の認証代行方法の１構成例として、クライアント
装置において暗号化を行う際に、このクライアント装置
の認証情報を暗号用公開鍵を用いて暗号化し、この暗号
化された情報を認証代行サーバ装置へ送信する手順と、
サービスプロバイダ装置において復号化を行う際に、認
証代行サーバ装置から受け取った暗号化された情報を暗
号用秘密鍵を用いて復号化して認証情報を取得し、この
認証情報を基にクライアント装置の認証を行う手順とを
有するものである。

【００２０】また、本発明の認証代行サービスシステム
として、認証代行サーバ装置（Ｓ）は、サービス提供
時、所望のサービスに対応したサービスプロバイダ装置
の暗号用公開鍵をクライアント装置へ配送し、クライア
ント装置から受け取った暗号化された情報をサービスプ
ロバイダ装置へ転送する手段を有し、クライアント装置
（Ｃ）は、サービスプロバイダ装置へ送信すべき情報を
認証代行サーバ装置から受け取った暗号用公開鍵を用い
て暗号化し、この暗号化された情報を認証代行サーバ装
置へ送信する手段を有し、サービスプロバイダ装置（Ｓ
Ｐ−Ａ，ＳＰ−Ｂ）は、認証代行サーバ装置から受け取
った暗号化された情報を暗号用秘密鍵を用いて復号化す
る手段を有するものである。また、本発明の認証代行サ
ービスシステムとして、認証代行サーバ装置（Ｓ）は、
サービス提供時、所望のサービスに対応したサービスプ
ロバイダ装置に対して、クライアント装置の暗号用公開
鍵を配送し、サービスプロバイダ装置から受け取った暗
号化された情報をクライアント装置へ転送する手段を有
し、サービスプロバイダ装置（ＳＰ−Ａ，ＳＰ−Ｂ）
は、クライアント装置へ送信すべき情報を認証代行サー
バ装置から受け取った暗号用公開鍵を用いて暗号化し、
この暗号化された情報を認証代行サーバ装置へ送信する
手段を有し、クライアント装置（Ｃ）は、認証代行サー
バ装置から受け取った暗号化された情報を暗号用秘密鍵
を用いて復号化する手段を有するものである。

【００２１】また、本発明の認証代行サービスシステム
として、認証代行サーバ装置（Ｓ）は、サービス提供
時、所望のサービスに対応したサービスプロバイダ装置
の暗号用公開鍵をクライアント装置へ配送し、クライア
ント装置から受け取った暗号化された情報をサービスプ
ロバイダ装置へ転送し、サービスプロバイダ装置から受
け取った暗号化された情報をクライアント装置へ転送す
る手段を有し、クライアント装置（Ｃ）は、サービスプ
ロバイダ装置との間の暗号通信用セッションキーあるい
はこのセッションキーの元となるデータを生成し、セッ
ションキーあるいはデータを認証代行サーバ装置から受
け取った暗号用公開鍵を用いて暗号化し、この暗号化さ
れた情報を認証代行サーバ装置へ送信した後、サービス
プロバイダ装置へ送信すべき情報をセッションキーを用
いて暗号化し、この暗号化された情報を認証代行サーバ
装置へ送信する手段を有し、サービスプロバイダ装置
（ＳＰ−Ａ，ＳＰ−Ｂ）は、認証代行サーバ装置から受
け取った暗号化された情報を暗号用秘密鍵を用いて復号
化してセッションキーを取得し、あるいは暗号用秘密鍵
を用いた復号化によりデータを取得して、このデータか
らセッションキーを生成した後、クライアント装置へ送
信すべき情報をセッションキーを用いて暗号化し、この
暗号化された情報を認証代行サーバ装置へ送信する手段
を有するものである。

【００２２】また、本発明の認証代行サービスシステム
の１構成例として、認証代行サーバ装置は、暗号用公開
鍵をクライアント装置へ配送する際に、暗号用公開鍵と
共に暗号用公開鍵証明書を配送する手段を有し、クライ
アント装置は、暗号用公開鍵を用いた暗号化を行う前
に、認証代行サーバ装置から受け取った暗号用公開鍵証
明書を基に暗号用公開鍵を検証する手段を有するもので
ある。また、本発明の認証代行サービスシステムの１構
成例として、クライアント装置は、暗号化を行う際に、
自装置の認証情報を暗号用公開鍵を用いて暗号化し、こ
の暗号化された情報を認証代行サーバ装置へ送信する手
段を有し、サービスプロバイダ装置は、復号化を行う際
に、認証代行サーバ装置から受け取った暗号化された情
報を暗号用秘密鍵を用いて復号化して認証情報を取得
し、この認証情報を基にクライアント装置の認証を行う
手段を有するものである。

【００２３】また、本発明の認証代行サーバ装置（Ｓ）
は、サービス提供時、所望のサービスに対応したサービ
スプロバイダ装置の暗号用公開鍵をクライアント装置へ
配送し、この暗号用公開鍵を用いて暗号化された情報を
クライアント装置から受け取り、暗号用秘密鍵を用いた
復号化を行わせるべく、暗号化された情報をサービスプ
ロバイダ装置へ転送する手段を有するものである。ま
た、本発明の認証代行サーバ装置（Ｓ）は、サービス提
供時、所望のサービスに対応したサービスプロバイダ装
置に対して、クライアント装置の暗号用公開鍵を配送
し、この暗号用公開鍵を用いて暗号化された情報をサー
ビスプロバイダ装置から受け取り、暗号用秘密鍵を用い
た復号化を行わせるべく、暗号化された情報をクライア
ント装置へ転送する手段を有するものである。

【００２４】また、本発明の認証代行サーバ装置（Ｓ）
は、サービス提供時、所望のサービスに対応したサービ
スプロバイダ装置の暗号用公開鍵をクライアント装置へ
配送し、この暗号用公開鍵を用いて暗号化された暗号通
信用セッションキーあるいはこのセッションキーの元と
なるデータをクライアント装置から受け取り、暗号用秘
密鍵を用いた復号化を行わせるべく、暗号化されたセッ
ションキーあるいはデータをサービスプロバイダ装置へ
転送した後、セッションキーを用いて暗号化された、ク
ライアント装置からの情報をサービスプロバイダ装置へ
転送すると共に、セッションキーを用いて暗号化され
た、サービスプロバイダ装置からの情報をクライアント
装置へ転送する手段を有するものである。また、本発明
の認証代行サーバ装置の１構成例は、クライアント装置
に暗号用公開鍵の検証を行わせるべく、暗号用公開鍵と
共に暗号用公開鍵証明書をクライアント装置へ配送する
手段を有するものである。

【００２５】また、本発明のクライアント装置（Ｃ）
は、認証代行サーバ装置からクライアント認証を受ける
ための署名を生成する署名生成手段を備えたＩＣカード
からなると共に、サービスプロバイダ装置へ送信すべき
情報を暗号用公開鍵を用いて暗号化する暗号化手段と、
ＩＣカードによって生成された署名を認証代行サーバ装
置へ送信し、認証代行サーバ装置から送信された暗号用
公開鍵を受け取って暗号化手段へ出力し、暗号化手段に
よって暗号化された情報を認証代行サーバ装置へ送信す
る送受信手段とを備えた処理装置からなるものである。
また、本発明のクライアント装置（Ｃ）は、認証代行サ
ーバ装置からクライアント認証を受けるための署名を生
成する署名生成手段と、サービスプロバイダ装置へ送信
すべき情報を暗号用公開鍵を用いて暗号化する暗号化手
段とを備えたＩＣカードからなると共に、ＩＣカードに
よって生成された署名を認証代行サーバ装置へ送信し、
認証代行サーバ装置から送信された暗号用公開鍵を受け
取ってＩＣカードへ出力し、ＩＣカードによって暗号化
された情報を認証代行サーバ装置へ送信する送受信手段
とを備えた処理装置からなるものである。

【００２６】

【発明の実施の形態】［実施の形態の１］次に、本発明
の実施の形態について図面を参照して詳細に説明する。
図１は本発明の第１の実施の形態となる認証代行サービ
スシステムの構成を示すブロック図である。本実施の形
態の認証代行サービスシステムは、前述の従来技術２あ
るいは従来技術３において、認証代行サーバ装置（以
下、認証代行サーバと略する）Ｓが複数のサービスプロ
バイダ装置（以下、サービスプロバイダと略する）ＳＰ
−Ａ，ＳＰ−Ｂの公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂを
クライアント装置（以下、クライアントと略する）Ｃに
サービス提供時に配送し、認証代行サーバＳには秘匿し
ておきたい情報をこの公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−
Ｂを用いてクライアントＣ側で暗号化させて認証代行サ
ーバＳに返却させ、この情報を認証代行サーバＳがサー
ビスプロバイダＳＰ−Ａ，ＳＰ−Ｂに送信し、サービス
プロバイダＳＰ−Ａ，ＳＰ−Ｂで秘密鍵ＳｋＳＰ−Ａ，
ＳｋＳＰ−Ｂによって復号化させることで、認証代行サ
ーバＳには漏洩することなく、クライアントＣからサー
ビスプロバイダＳＰ−Ａ，ＳＰ−Ｂへの情報転送を実現
するものである。

【００２７】サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂと
クライアントＣとは、ネットワークを介して接続され、
このネットワークの途中に認証代行サーバ装置Ｓが設け
られている。図１において、ＰｋＳＰ−Ａ，ＰｋＳＰ−
ＢはそれぞれサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂの
暗号用公開鍵、ＳｋＳＰ−Ａ，ＳｋＳＰ−Ｂそれぞれサ
ービスプロバイダＳＰ−Ａ，ＳＰ−Ｂの暗号用秘密鍵で
ある。また、ＳｋＵ−Ａ，ＳｋＵ−Ｂはそれぞれサービ
スプロバイダＳＰ−Ａ，ＳＰ−Ｂからサービスを受ける
ための秘密情報、ＳｋＰは認証代行サーバＳ自身の秘密
情報である。本実施の形態のシステムが従来技術２に対
応する方式の場合には、秘密情報ＳｋＵ−Ａ，ＳｋＵ−
Ｂを用いてクライアントＣの認証が行われ、従来技術３
に対応する方式の場合には、秘密情報ＳｋＰを用いてク
ライアントＣの認証が行われる。

【００２８】次に、このような認証代行サービスシステ
ムの動作を説明する。サービス提供時、認証代行サーバ
Ｓは、クライアントＣが要求するサービスに応じて適切
なサービスプロバイダＳＰ−Ａの暗号用公開鍵ＰｋＳＰ
−ＡをクライアントＣに配送すると共に、この公開鍵Ｐ
ｋＳＰ−Ａを使った情報の暗号化要求、秘匿情報に関連
したその他情報変換要求、暗号化された情報及び変換さ
れた情報の返却要求をクライアントＣに対して行う。

【００２９】ここで、秘匿情報に関連したその他情報変
換要求とは、秘匿情報をサービスプロバイダＳＰ−Ａ，
ＳＰ−Ｂでも復号化できない形態へ変換する処理の要求
であり、サービスにより必要な場合のみ出されるもの
で、例えば一方向ハッシュ演算を指す。

【００３０】クライアントＣは、認証代行サーバＳの要
求に応じて、サービスプロバイダＳＰ−Ａへ送信すべき
情報を公開鍵ＰｋＳＰ−Ａを用いて暗号化し、暗号化し
た情報を認証代行サーバＳに送信する。また、クライア
ントＣは、秘匿情報に関連したその他情報変換要求がな
された場合、ハッシュ演算等の変換を行った情報を暗号
化した情報と共に認証代行サーバＳに送信する。

【００３１】認証代行サーバＳは、クライアントＣから
送信された情報を受け取り、この情報をサービスプロバ
イダＳＰ−Ａへ転送すると共に、サービスプロバイダＳ
Ｐ−Ａに対して復号化要求を行う。サービスプロバイダ
ＳＰ−Ａは、認証代行サーバＳから送信された情報を受
け取り、この情報を自身が有する秘密鍵ＳｋＳＰ−Ａを
用いて復号化する。

【００３２】こうして、クライアントＣからサービスプ
ロバイダＳＰ−Ａへの情報が認証代行サーバＳに漏洩す
ることを防止でき、前記問題点１の部分的な解決が可能
になる。なお、以上の動作説明では、サービス提供がサ
ービスプロバイダＳＰ−Ａによって行われる場合につい
て説明しているが、サービス提供がサービスプロバイダ
ＳＰ−Ｂによって行われる場合には、公開鍵ＰｋＳＰ−
Ａの代わりにＰｋＳＰ−Ｂが用いられ、クライアントＣ
からの情報がサービスプロバイダＳＰ−Ｂに転送され、
サービスプロバイダＳＰ−Ｂが秘密鍵ＳｋＳＰ−Ｂを用
いて情報を復号化する。

【００３３】また、前記暗号化要求、秘匿情報に関連し
たその他情報変換要求、暗号化された情報及び変換され
た情報の返却要求は、クライアントＣが自律的に行うこ
とで省略することができ、同様に前記復号化要求は、サ
ービスプロバイダＳＰ−Ａ，ＳＰ−Ｂが自律的に行うこ
とで省略することができる。

【００３４】また、サービスプロバイダＳＰ−Ａ，ＳＰ
−Ｂからサービス提供を受けるためには、前述の従来技
術２あるいは従来技術３で説明したように認証代行サー
バＳがクライアントＣに代わってサービスプロバイダＳ
Ｐ−Ａ，ＳＰ−Ｂからクライアント認証を受ける処理
（秘密情報ＳｋＵ−Ａ，ＳｋＵ−ＢあるいはＳｋＰによ
る署名の生成とこの署名のサービスプロバイダＳＰ−
Ａ，ＳＰ−Ｂへの送信など）が必要である。この処理
は、認証代行サーバＳによる公開鍵ＰｋＳＰ−Ａ，Ｐｋ
ＳＰ−Ｂの配送からサービスプロバイダＳＰ−Ａ，ＳＰ
−Ｂによる情報の復号化に至る一連のシーケンスより前
の時点、クライアントＣから受け取った情報をサービス
プロバイダＳＰ−Ａ，ＳＰ−Ｂに配送する時点、あるい
は前記一連のシーケンスより後の時点のいずれに行って
もよい。

【００３５】［実施の形態の２］図２は本発明の第２の
実施の形態となる認証代行サービスシステムの構成を示
すブロック図である。本実施の形態の認証代行サービス
システムは、前述の従来技術２あるいは従来技術３にお
いて、認証代行サーバＳがクライアントＣの公開鍵Ｐｋ
Ｕ’−Ａ，ＰｋＵ’−ＢをサービスプロバイダＳＰ−
Ａ，ＳＰ−Ｂに配送し、認証代行サーバＳには秘匿して
おきたい情報をこの公開鍵ＰｋＵ’−Ａ，ＰｋＵ’−Ｂ
を用いてサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ側で暗
号化させて認証代行サーバＳに返却させ、この情報を認
証代行サーバＳがクライアントＣに送信し、クライアン
トＣで秘密鍵ＳｋＵ’−Ａ，ＳｋＵ’−Ｂによって復号
化させることで、認証代行サーバＳには漏洩することな
く、サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂからクライ
アントＣへの情報転送を実現するものである。

【００３６】図２において、ＣｅｒｔＵ’−Ａ，Ｃｅｒ
ｔＵ’−ＢはそれぞれサービスプロバイダＳＰ−Ａ，Ｓ
Ｐ−Ｂに対するクライアントＣの暗号用公開鍵証明書、
ＰｋＵ’−Ａ，ＰｋＵ’−Ｂはそれぞれサービスプロバ
イダＳＰ−Ａ，ＳＰ−Ｂに対するクライアントＣの暗号
用公開鍵、ＳｋＵ’−Ａ，ＳｋＵ’−Ｂはそれぞれサー
ビスプロバイダＳＰ−Ａ，ＳＰ−Ｂに対するクライアン
トＣの暗号用秘密鍵である。本実施の形態のシステムが
従来技術２に対応する方式の場合には、秘密情報ＳｋＵ
−Ａ，ＳｋＵ−Ｂを用いてクライアントＣの認証が行わ
れ、従来技術３に対応する方式の場合には、秘密情報Ｓ
ｋＰを用いてクライアントＣの認証が行われる。

【００３７】次に、このような認証代行サービスシステ
ムの動作を説明する。サービス提供時、認証代行サーバ
Ｓは、クライアントＣが要求するサービスに応じた適切
なサービスプロバイダＳＰ−Ａに対して、クライアント
Ｃの暗号用公開鍵ＰｋＵ’−Ａを暗号用公開鍵証明書Ｃ
ｅｒｔＵ’−Ａに付加する形で配送すると共に、この公
開鍵ＰｋＵ’−Ａを使った情報の暗号化要求を行う。

【００３８】この認証代行サーバＳの要求により、サー
ビスプロバイダＳＰ−Ａは、クライアントＣへ送信すべ
き情報を暗号用公開鍵証明書ＣｅｒｔＵ’−Ａに含まれ
る公開鍵ＰｋＵ’−Ａを用いて暗号化し、暗号化した情
報を認証代行サーバＳに送信する。認証代行サーバＳ
は、サービスプロバイダＳＰ−Ａから送信された情報を
受け取り、この情報をクライアントＣへ転送すると共
に、クライアントＣに対して復号化要求を行う。

【００３９】クライアントＣは、認証代行サーバＳから
送信された情報を受け取り、この情報を自身が有する秘
密鍵ＳｋＵ’−Ａを用いて復号化する。こうして、サー
ビスプロバイダＳＰ−ＡからクライアントＣへの情報が
認証代行サーバＳに漏洩することを防止でき、前記問題
点１の部分的な解決が可能になる。なお、以上の動作説
明では、サービス提供がサービスプロバイダＳＰ−Ａに
よって行われる場合について説明しているが、サービス
提供がサービスプロバイダＳＰ−Ｂによって行われる場
合には、証明書ＣｅｒｔＵ’−Ａ、公開鍵ＰｋＵ’−Ａ
の代わりにそれぞれＣｅｒｔＵ’−Ｂ、ＰｋＵ’−Ｂが
用いられ、サービスプロバイダＳＰ−Ｂからの情報がク
ライアントＣに転送され、クライアントＣが秘密鍵Ｓｋ
Ｕ’−Ｂを用いて情報を復号化する。

【００４０】また、前記暗号化要求は、サービスプロバ
イダＳＰ−Ａ，ＳＰ−Ｂが自律的に行うことで省略する
ことができ、同様に前記復号化要求は、クライアントＣ
が自律的に行うことで省略することができる。本実施の
形態では、秘密鍵ＳｋＵ’−Ａ，ＳｋＵ’−Ｂをクライ
アントＣで管理しなくてはならず、サービス毎に秘密鍵
が必要になってしまう、ただし、秘密鍵ＳｋＵ’−Ａ，
ＳｋＵ’−Ｂに対応する公開鍵証明書ＣｅｒｔＵ’−
Ａ，ＣｅｒｔＵ’−Ｂの管理は認証代行サーバＳに委託
することが可能である。そのため、認証代行サーバＳの
有り／無しに関わらず、そもそも暗号用の秘密鍵が必要
なサービスに対しての適用が有効である。

【００４１】また、認証代行サーバＳがクライアントＣ
に代わってサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂから
クライアント認証を受ける処理（秘密情報ＳｋＵ−Ａ，
ＳｋＵ−ＢあるいはＳｋＰによる署名の生成とこの署名
のサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂへの送信な
ど）は、認証代行サーバＳによる公開鍵ＰｋＵ’−Ａ，
ＰｋＵ’−Ｂの配送からクライアントＣによる情報の復
号化に至る一連のシーケンスより前の時点、あるいは前
記一連のシーケンスより後の時点のいずれに行ってもよ
い。

【００４２】［実施の形態の３］図３は本発明の第３の
実施の形態となる認証代行サービスシステムの構成を示
すブロック図である。本実施の形態の認証代行サービス
システムは、実施の形態の１において、暗号用公開鍵Ｐ
ｋＳＰ−Ａ，ＰｋＳＰ−ＢのクライアントＣへの配送時
に、セッションキーの生成あるいはセッションキーの元
となるデータの生成をクライアントＣに対して要求し、
さらにこれらを暗号用公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−
Ｂを用いて暗号化させた上で返却させ、暗号化された情
報をサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂへ転送する
ことで、認証代行サーバＳには漏洩することなく、クラ
イアントＣとサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ間
の双方向の情報転送を実現するものである。

【００４３】図３において、ＳＳｋＡ，ＳＳｋＢはそれ
ぞれクライアントＣとサービスプロバイダＳＰ−Ａ間、
クライアントＣとサービスプロバイダＳＰ−Ｂ間の暗号
通信用セッションキー、ＳｄＳＳＫＡ，ＳｄＳＳｋＢは
それぞれ暗号通信用セッションキーＳＳｋＡ，ＳＳｋＢ
の生成の元となる例えば乱数等のデータである。本実施
の形態のシステムが従来技術２に対応する方式の場合に
は、秘密情報ＳｋＵ−Ａ，ＳｋＵ−Ｂを用いてクライア
ントＣの認証が行われ、従来技術３に対応する方式の場
合には、秘密情報ＳｋＰを用いてクライアントＣの認証
が行われる。

【００４４】次に、このような認証代行サービスシステ
ムの動作を説明する。サービス提供時、認証代行サーバ
Ｓは、クライアントＣが要求するサービスに応じて適切
なサービスプロバイダＳＰ−Ａの暗号用公開鍵ＰｋＳＰ
−ＡをクライアントＣに配送すると共に、暗号通信用セ
ッションキーＳＳｋＡの生成要求あるいはセッションキ
ーＳＳｋＡの元となるデータＳｄＳＳＫＡの生成要求、
公開鍵ＰｋＳＰ−Ａを用いたセッションキーＳＳｋＡあ
るいはデータＳｄＳＳＫＡの暗号化要求、暗号化された
情報の返却要求をクライアントＣに対して行う。

【００４５】この認証代行サーバＳの要求により、クラ
イアントＣは、暗号通信用セッションキーＳＳｋＡを生
成する。また、クライアントＣは、場合によってはセッ
ションキーＳＳｋＡの元となるデータＳｄＳＳＫＡを生
成する。そして、クライアントＣは、セッションキーＳ
ＳｋＡあるいはデータＳｄＳＳＫＡを公開鍵ＰｋＳＰ−
Ａを用いて暗号化し、暗号化した情報を認証代行サーバ
Ｓに送信する。

【００４６】認証代行サーバＳは、クライアントＣから
送信された情報を受け取り、この情報をサービスプロバ
イダＳＰ−Ａへ転送すると共に、必要であればデータＳ
ｄＳＳＫＡから暗号通信用セッションキーＳＳｋＡの生
成をサービスプロバイダＳＰ−Ａに対して要求する。

【００４７】サービスプロバイダＳＰ−Ａは、認証代行
サーバＳから送信された情報を受け取り、この情報を自
身が有する秘密鍵ＳｋＳＰ−Ａを用いて復号化し、セッ
ションキーＳＳｋＡを取得する。また、サービスプロバ
イダＳＰ−Ａは、認証代行サーバＳからセッションキー
ＳＳｋＡの生成を要求された場合、認証代行サーバＳか
ら送信された情報を秘密鍵ＳｋＳＰ−Ａを用いて復号化
して、データＳｄＳＳＫＡを取得して、このデータＳｄ
ＳＳＫＡからセッションキーＳＳｋＡを生成する。

【００４８】以後、クライアントＣとサービスプロバイ
ダＳＰ−Ａ間の双方向の通信について安全な情報のやり
とりが可能となる。すなわち、クライアントＣからサー
ビスプロバイダＳＰ−Ａへ情報を送信する場合、クライ
アントＣは、送信すべき情報をセッションキーＳＳｋＡ
を用いて暗号化した後に送信し、暗号化された情報を認
証代行サーバＳを介して受け取ったサービスプロバイダ
ＳＰ−Ａは、自身が有するセッションキーＳＳｋＡを用
いて情報を復号化する。

【００４９】一方、サービスプロバイダＳＰ−Ａからク
ライアントＣへ情報を送信する場合、サービスプロバイ
ダＳＰ−Ａは、送信すべき情報をセッションキーＳＳｋ
Ａを用いて暗号化した後に送信し、暗号化された情報を
認証代行サーバＳを介して受け取ったクライアントＣ
は、自身が有するセッションキーＳＳｋＡを用いて情報
を復号化する。

【００５０】こうして、クライアントＣからサービスプ
ロバイダＳＰ−Ａへの情報のみならず、サービスプロバ
イダＳＰ−ＡからクライアントＣへの情報配送において
も、認証代行サーバＳに情報が漏洩することを防止する
ことが可能になる。なお、以上の動作説明では、サービ
ス提供がサービスプロバイダＳＰ−Ａによって行われる
場合について説明しているが、サービス提供がサービス
プロバイダＳＰ−Ｂによって行われる場合には、公開鍵
ＰｋＳＰ−Ａ、セッションキーＳＳｋＡ、データＳｄＳ
ＳＫＡの代わりにそれぞれＰｋＳＰ−Ｂ、セッションキ
ーＳＳｋＢ、情報ＳｄＳＳＫＢが用いられ、クライアン
トＣからの情報がサービスプロバイダＳＰ−Ｂに転送さ
れ、サービスプロバイダＳＰ−ＢがデータＳｄＳＳＫＢ
からセッションキーＳＳｋＢを生成する。

【００５１】また、前記生成要求、暗号化要求、暗号化
された情報の返却要求はクライアントＣが自律的に行う
ことで省略することができ、同様に前記生成要求はサー
ビスプロバイダＳＰ−Ａ，ＳＰ−Ｂが自律的に行うこと
で省略することができる。

【００５２】また、認証代行サーバＳがクライアントＣ
に代わってサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂから
クライアント認証を受ける処理（秘密情報ＳｋＵ−Ａ，
ＳｋＵ−ＢあるいはＳｋＰによる署名の生成とこの署名
のサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂへの送信な
ど）は、認証代行サーバＳによる公開鍵ＰｋＳＰ−Ａ，
ＰｋＳＰ−Ｂの配送からサービスプロバイダＳＰ−Ａ，
ＳＰ−ＢによるセッションキーＳＳｋＡの生成に至る一
連のシーケンスより前の時点、暗号化されたセッション
キーＳＳｋＡ，ＳＳｋＢあるいはデータＳｄＳＳＫＡ，
ＳｄＳＳｋＢをサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ
に配送する時点、あるいは前記一連のシーケンスより後
の時点のいずれに行ってもよい。

【００５３】［実施の形態の４］図４は本発明の第４の
実施の形態となる認証代行サービスシステムの構成を示
すブロック図である。実施の形態の１あるいは実施の形
態の３では、サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂの
暗号用公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂを誰がどのよ
うに検証するかという問題が存在する。例えば、認証代
行サーバＳに公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂの検証
（例えば、公開鍵証明書の認証局署名の検証やＣＲＬの
チェックなど）を委託した場合には、以下のような問題
が生じる。

【００５４】すなわち、偽の公開鍵を認証代行サーバＳ
からクライアントＣに配送し、クライアントＣからサー
ビスプロバイダＳＰ−Ａ，ＳＰ−Ｂへの情報を認証代行
サーバＳが認知している、偽の公開鍵に対応する秘密鍵
を用いて復号化した上で、この復号化した情報を改めて
正しい公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂを用いて暗号
化してサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂへ送信す
るという操作を行えば、認証代行サーバＳにおいて情報
を不正に取得することが可能になる。

【００５５】そこで、本実施の形態の認証代行サービス
システムは、サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂの
暗号用公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂの検証を認証
代行サーバＳからクライアントＣに対して要求する。す
なわち、認証代行サーバＳは、暗号用公開鍵ＰｋＳＰ−
Ａ，ＰｋＳＰ−Ｂと共に、暗号用公開鍵証明書Ｃｅｒｔ
ＳＰ−Ａ，ＣｅｒｔＳＰ−ＢをクライアントＣへ配送す
る。

【００５６】クライアントＣは、例えば上位認証局の証
明書をサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ毎に保持
しており、認証代行サーバＳから配送されてきた公開鍵
証明書ＣｅｒｔＳＰ−Ａ，ＣｅｒｔＳＰ−Ｂを上位認証
局の証明書を用いて検証する。また、クライアントＣ
は、公開鍵証明書ＣｅｒｔＳＰ−Ａ，ＣｅｒｔＳＰ−Ｂ
が失効していないかどうかの確認を証明書取り消しリス
ト（Certificate Revocation List 、以下、ＣＲＬと略
する）に基づいて行う。

【００５７】こうして、暗号用公開鍵ＰｋＳＰ−Ａ，Ｐ
ｋＳＰ−Ｂの検証を行うことができる。なお、認証代行
サーバＳはクライアントＣにとっては十分に信頼でき、
偽の公開鍵をクライアントＣに配送することは考慮しな
くてよい場合が多い。すなわち、一般には、クライアン
トＣとサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ間の双方
向の通信に係る情報漏洩については信頼しきれないが、
偽の公開鍵配送については考慮しなくてよいという場合
が多く、実施の形態の１あるいは３で十分である。

【００５８】その理由は、認証代行サーバＳの運用作業
者や認証代行サーバＳに不正にアクセスする外部侵入者
にとっては、サーバＳ内で平文になる情報を盗む方が、
偽の公開鍵配送による一連の不正行為を実施するよりも
実行が容易だからである。また、前記検証要求は、クラ
イアントＣが公開鍵の検証を自律的に行うことで省略す
ることができる。

【００５９】［実施の形態の５］図５は本発明の第５の
実施の形態となる認証代行サービスシステムの構成を示
すブロック図である。本実施の形態の認証代行サービス
システムは、実施の形態の１あるいは３のシステムにお
いて、公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂを用いて暗号
化される、クライアントＣからサービスプロバイダＳＰ
−Ａ，ＳＰ−Ｂへの情報の配送を利用して、クライアン
トＣに認証代行サーバＳで復号化ができないような形で
の認証情報を要求し、この認証情報を認証代行サーバＳ
からサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂへ転送し
て、サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂでクライア
ント認証を行うものである。

【００６０】図５において、Ａ，Ｂはそれぞれサービス
プロバイダＳＰ−Ａ，ＳＰ−Ｂに対応するクライアント
Ｃの認証情報である。認証代行サーバＳは、暗号用公開
鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−ＢをクライアントＣに配送
する際に、この公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂを使
った認証情報Ａ，Ｂの暗号化要求をクライアントＣに対
して行う。

【００６１】クライアントＣは、サービスプロバイダＳ
Ｐ−Ａへ送信すべき情報を公開鍵ＰｋＳＰ−Ａを用いて
暗号化する際に、公開鍵ＰｋＳＰ−Ａを用いて認証情報
（パスワード）Ａを暗号化し、この暗号化された認証情
報Ａを実施の形態の１あるいは３で説明した他の情報と
共に認証代行サーバＳへ送信する。同様に、クライアン
トＣは、サービスプロバイダＳＰ−Ｂへ送信すべき情報
を公開鍵ＰｋＳＰ−Ｂを用いて暗号化する際に、公開鍵
ＰｋＳＰ−Ｂを用いて認証情報（パスワード）Ｂを暗号
化し、この暗号化された認証情報Ｂを実施の形態の１あ
るいは３で説明した他の情報と共に認証代行サーバＳへ
送信する。

【００６２】サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ
は、クライアントＣから送信され認証代行サーバＳによ
って転送された情報を受け取り、この情報を暗号用秘密
鍵ＳｋＳＰ−Ａ，ＳｋＳＰ−Ｂを用いて復号化して、認
証情報Ａ，Ｂを取得する。そして、サービスプロバイダ
ＳＰ−Ａ，ＳＰ−Ｂは、認証情報Ａ，Ｂを基にクライア
ントＣの認証を行う。

【００６３】こうして、認証代行サーバＳがクライアン
トＣになりすますことを防ぐことができ、前記問題点２
を解決することができる。また、認証代行サーバＳが自
身の秘密情報ＳｋＰでクライアント認証を受けたとして
も、サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂは、クライ
アントＣの直接認証が可能で、かつ認証代行サーバＳが
クライアントＣになりすますことを防ぐ手段を有してい
ることになり、認証代行サーバＳの責任を軽減させるこ
とが可能となる（前記問題点３の解決）。

【００６４】認証代行サーバＳを用いる利点の一つは、
クライアントＣで管理する秘密情報の数を減少させるこ
とであるから、本実施の形態での認証情報Ａ，Ｂは認証
代行サーバＳで管理しているものと比べて簡易なものと
することが一般的となる。例えば、認証代行サーバＳ
は、秘密情報ＳｋＵ−Ａ，ＳｋＵ−ＢあるいはＳｋＰを
利用したクライアント認証処理を行い、クライアントＣ
は、前記秘密情報よりも簡易なパスワードを認証情報と
して認証代行サーバＳに秘匿した形でサービスプロバイ
ダＳＰ−Ａ，ＳＰ−Ｂに送ることでクライアント認証を
受ける。

【００６５】なお、毎回、同一のパスワードを転送する
場合には、認証代行サーバＳによるリプレイ攻撃が可能
になるため、シリアル値や時刻情報、あるいは実施の形
態の３で説明したセッションキーと認証情報とを組み合
わせて転送することも有効である。

【００６６】［実施の形態の６］図６は本発明の第６の
実施の形態となる認証代行サーバＳの構成を示すブロッ
ク図である。図６に示す認証代行サーバＳは、実施の形
態の１〜５の認証代行サービスシステムを実現するもの
である。認証代行サーバＳは、少なくともクライアント
Ｃの認証機能、及び暗号用公開鍵配送機能を持ち、実施
の形態の３以外の場合には暗号用公開鍵証明書検証機能
を持つ。

【００６７】なお、認証代行サーバＳがクライアントＣ
に代わってサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂから
クライアント認証を受ける処理を従来技術２の方式で行
う場合には、ＳｋＰ記憶器１０及びＣｅｒｔＰ記憶器１
１は不要であり、従来技術３の方式で行う場合には、Ｓ
ｋＵ−Ａ記憶器８及びＣｅｒｔＵ−Ａ記憶器９は不要で
ある。

【００６８】ＳｋＵ−Ｐ記憶器１は、認証代行サーバＳ
とクライアントＣ間の認証に用いるための秘密情報Ｓｋ
Ｕ−Ｐを記憶し、ＣｅｒｔＵ−Ｐ記憶器２は、秘密情報
ＳｋＵ−Ｐに対応した証明書ＣｅｒｔＵ−Ｐを記憶して
いる。秘密情報ＳｋＵ−Ｐと証明書ＣｅｒｔＵ−Ｐと
は、各クライアントＣ毎に記憶されている。

【００６９】ＳｋＵ−Ｐ検証器３は、クライアントＣか
ら送信され送受信装置１４で受信された秘密情報ＳｋＵ
−Ｐ、証明書ＣｅｒｔＵ−Ｐ、あるいは秘密情報ＳｋＵ
−Ｐと証明書ＣｅｒｔＵ−Ｐとを基に、ＳｋＵ−Ｐ記憶
器１及びＣｅｒｔＵ−Ｐ記憶器２を参照して、クライア
ントＣの認証を行う。ＳｋＵ−Ｐ検証器３は、一般には
各クライアントＣの識別番号とそれぞれの秘密情報Ｓｋ
Ｕ−Ｐの対応表を参照することで、クライアントＣの認
証を行う。

【００７０】ＳＰ−Ａ公開鍵記憶器４は、暗号用公開鍵
ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂ（ＰｋＵ’−Ａ，ＰｋＵ’
−Ｂ）を記憶し、ＳＰ−Ａ公開鍵証明書ＣＲＬ記憶器５
は、この暗号用公開鍵に対応する公開鍵証明書Ｃｅｒｔ
ＳＰ−Ａ，ＣｅｒｔＳＰ−Ｂ（ＣｅｒｔＵ’−Ａ，Ｃｅ
ｒｔＵ’−Ｂ）のＣＲＬを記憶し、ＳＰ−Ａ上位認証局
公開鍵証明書記憶器６は、上位認証局の公開鍵証明書を
記憶している。暗号用公開鍵とＣＲＬと上位認証局の公
開鍵証明書とは、各サービスプロバイダＳＰ−Ａ，ＳＰ
−Ｂ毎に記憶されている。

【００７１】ＳＰ公開鍵証明書検証器７は、ＳＰ−Ａ公
開鍵記憶器４、ＳＰ−Ａ公開鍵証明書ＣＲＬ記憶器５及
びＳＰ−Ａ上位認証局公開鍵証明書記憶器６を参照し
て、暗号用公開鍵の検証を行う。なお、図６では図示し
ていないが、実際には、ＣＲＬを取得する手段と、上位
認証局公開鍵証明書を取得する手段が別途必要となる。

【００７２】ＳｋＵ−Ａ記憶器８は、秘密情報ＳｋＵ−
Ａ，ＳｋＵ−Ｂを記憶し、ＣｅｒｔＵ−Ａ記憶器９は、
秘密情報ＳｋＵ−Ａ，ＳｋＵ−Ｂに対応した証明書Ｃｅ
ｒｔＵ−Ａ，ＣｅｒｔＵ−Ｂを記憶している。秘密情報
ＳｋＵ−Ａ，ＳｋＵ−Ｂと証明書ＣｅｒｔＵ−Ａ，Ｃｅ
ｒｔＵ−Ｂとは、各サービスプロバイダＳＰ−Ａ，ＳＰ
−Ｂ毎及び各クライアントＣ毎に記憶されている。

【００７３】ＳｋＰ記憶器１０は、サーバＳ自身の秘密
情報ＳｋＰを記憶し、ＣｅｒｔＰ記憶器１１は、秘密情
報ＳｋＰに対応した証明書ＣｅｒｔＰを記憶している。
署名生成器１２は、所定の通信文を秘密情報ＳｋＵ−
Ａ，ＳｋＵ−ＢあるいはＳｋＰを用いて暗号化した署名
を生成し、この署名を送受信装置１４を介してサービス
プロバイダＳＰ−Ａ，ＳＰ−Ｂへ送信する。場合によっ
ては、署名生成器１２は、前記署名と共に証明書Ｃｅｒ
ｔＵ−Ａ，ＣｅｒｔＵ−ＢあるいはＣｅｒｔＰをサービ
スプロバイダＳＰ−Ａ，ＳＰ−Ｂへ送信する。

【００７４】代行処理部１３は、実施の形態の１〜５で
説明した処理以外の代行処理を必要に応じて行う。送受
信装置１４は、ネットワークを介してクライアントＣ及
びサービスプロバイダＳＰ−Ａ，ＳＰ−Ｂと接続され、
クライアントＣ及びサービスプロバイダＳＰ−Ａ，ＳＰ
−Ｂとの間で情報の送受信を行う。

【００７５】なお、本実施の形態では、クライアント認
証として公開鍵暗号を利用した認証方式によるものを想
定しているが、認証方式によっては署名生成器１２、Ｓ
ｋＵ−Ｐ検証器３、及び証明書Ｃｅｒｔ類の記憶器５，
６，９，１１は不必要になる。例えば、パスワード認証
では証明書は必要がなく、また署名生成器１２も必要な
い。

【００７６】以上のような認証代行サーバＳは、インタ
ーネット上などネットワーク上のサーバ、企業内ＬＡＮ
や家庭内ＬＡＮからインターネットなど広域ネットワー
クヘのゲートウェイとして設置が可能であり、例えば、
ワークステーション、パーソナルコンピュータ、ルー
タ、ターミナルアダプタなどの上でのソフトウェア、ハ
ードウェア及び周辺機器として実現される。

【００７７】［実施の形態の７］図７は本発明の第７の
実施の形態となるクライアントＣの構成を示すブロック
図である。図７に示すクライアントＣは、実施の形態の
１〜５の認証代行サービスシステムを実現するものであ
る。クライアントＣは、少なくとも暗号用公開鍵受信機
能、暗号用公開鍵による暗号化機能を持ち、実施の形態
の２の場合にはクライアント暗号用秘密鍵による復号化
機能、実施の形態の３の場合にはセッションキー生成／
送信機能及びセッションキーによる暗号化／復号化機
能、実施の形態の４の場合には暗号用公開鍵証明書検証
機能を持つ。

【００７８】つまり、実施の形態の２以外の場合には、
ＳｋＵ'−Ａ記憶器２６及び復号器２７は不要であり、
実施の形態の３以外の場合には、ＳＳｋ生成器２８、Ｓ
Ｓｋ一時記憶器２９、ＳｄＳＳＫ生成器３０及び暗号化
／復号化器３１は不要であり、実施の形態の４以外の場
合には、ＳＰ公開鍵証明書ＣＲＬ記憶器３２、ＳＰ上位
認証局公開鍵証明書記憶器３３及びＳＰ公開鍵証明書検
証器３４は不要である。

【００７９】ＳｋＵ−Ｐ記憶器２１は、認証代行サーバ
Ｓと自クライアントＣ間の認証に用いるための秘密情報
ＳｋＵ−Ｐを記憶し、ＣｅｒｔＵ−Ｐ記憶器２２は、秘
密情報ＳｋＵ−Ｐに対応した証明書ＣｅｒｔＵ−Ｐを記
憶している。署名生成器２３は、所定の通信文を秘密情
報ＳｋＵ−Ｐを用いて暗号化した署名を生成し、この署
名を送受信装置３６を介して認証代行サーバＳへ送信す
る。場合によっては、署名生成器２３は、前記署名と共
に証明書ＣｅｒｔＵ−Ｐを認証代行サーバＳへ送信す
る。

【００８０】ＳＰ公開鍵一時記憶器２４は、認証代行サ
ーバＳから送信され送受信装置３６で受信された暗号用
公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂを記憶している。暗
号化器２５は、この暗号用公開鍵ＰｋＳＰ−Ａ，ＰｋＳ
Ｐ−Ｂを用いて情報の暗号化を行い、暗号化された情報
を送受信装置３６を介して認証代行サーバＳへ送信す
る。

【００８１】ＳｋＵ'−Ａ記憶器２６は、暗号用秘密鍵
ＳｋＵ’−Ａ，ＳｋＵ’−Ｂを記憶している。この暗号
用秘密鍵は、各サービスプロバイダＳＰ−Ａ，ＳＰ−Ｂ
毎に記憶されている。復号器２７は、認証代行サーバＳ
から送信され送受信装置３６で受信された情報を暗号用
秘密鍵ＳｋＵ’−Ａ，ＳｋＵ’−Ｂを用いて復号化す
る。

【００８２】ＳＳｋ生成器２８は、暗号通信用セッショ
ンキーＳＳｋＡ，ＳＳｋＢを生成し、ＳＳｋ一時記憶器
２９は、この暗号通信用セッションキーＳＳｋＡ，ＳＳ
ｋＢを記憶する。ＳｄＳＳＫ生成器３０は、セッション
キーＳＳｋＡ，ＳＳｋＢの元となるデータＳｄＳＳＫ
Ａ，ＳｄＳＳｋＢを生成する。

【００８３】暗号化／復号化器３１は、送信すべき情報
をセッションキーＳＳｋＡ，ＳＳｋＢを用いて暗号化
し、暗号化された情報を送受信装置３６を介して認証代
行サーバＳへ送信する。また、暗号化／復号化器３１
は、認証代行サーバＳから送信され送受信装置３６で受
信された、暗号化された情報をセッションキーＳＳｋ
Ａ，ＳＳｋＢを用いて復号化する。

【００８４】ＳＰ公開鍵証明書ＣＲＬ記憶器３２は、暗
号用公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂに対応する公開
鍵証明書ＣｅｒｔＳＰ−Ａ，ＣｅｒｔＳＰ−ＢのＣＲＬ
を記憶し、ＳＰ上位認証局公開鍵証明書記憶器３３は、
上位認証局の公開鍵証明書を記憶している。ＣＲＬと上
位認証局の公開鍵証明書とは、各サービスプロバイダＳ
Ｐ−Ａ，ＳＰ−Ｂ毎に記憶されている。

【００８５】ＳＰ公開鍵証明書検証器３４は、ＳＰ公開
鍵証明書ＣＲＬ記憶器３２及びＳＰ上位認証局公開鍵証
明書記憶器３３を参照して、認証代行サーバＳから送信
され送受信装置３６で受信された暗号用公開鍵ＰｋＳＰ
−Ａ，ＰｋＳＰ−Ｂの検証を行う。なお、図７では図示
していないが、実際には、ＣＲＬを取得する手段と、上
位認証局公開鍵証明書を取得する手段が別途必要とな
る。

【００８６】入出力装置３５は、クライアントＣの利用
者からの指示が入力されると、この指示をクライアント
Ｃ内の各構成に出力すると共に、利用者に対して情報を
出力する。送受信装置３６は、ネットワークを介して認
証代行サーバＳと接続され、認証代行サーバＳとの間で
情報の送受信を行う。

【００８７】なお、本実施の形態においても、認証代行
サーバＳに対するクライアント認証機能は公開鍵暗号方
式を想定しているが、認証方式によっては不必要になる
回路が存在する。以上のようなクライアント装置Ｃは、
パーソナルコンピュータ上のソフトウェアとして実現さ
れる。また、一部若しくは全部の機能をスマートカード
（ＩＣカード）などの安全なデバイス上で実現すること
も可能である。

【００８８】例えば、ＳｋＵ−Ｐ記憶器２１、Ｃｅｒｔ
Ｕ−Ｐ記憶器２２及び署名生成器２３の機能をスマート
カードに持たせ、残りの機能をスマートカードのリーダ
／ライタ機能を備えたコンピュータ、電話機あるいはセ
ットトップボックス等の処理装置に持たせることが可能
であり、ＳｋＵ−Ｐ記憶器２１、ＣｅｒｔＵ−Ｐ記憶器
２２及び署名生成器２３の機能と共にＳＰ公開鍵一時記
憶器２４及び暗号化器２５の機能をスマートカードに持
たせ、残りの機能を処理装置に持たせることも可能であ
る。

【００８９】［実施の形態の８］図８、図９は本発明の
第８の実施の形態となる認証代行サービスシステムの動
作を示すシーケンス図である。本実施の形態の認証代行
サービスシステムは、実施の形態の５で説明したシステ
ムをネットワークデビット決済用サーバ管理型ウォレッ
トに適用したものである。

【００９０】ここで、ネットワークデビット決済の方式
としては、ＳＥＴ（Online PIN Extensionを含む）ある
いはＳＥＣＥを想定している。ネットワークデビット決
済では、利用者、加盟店、金融機関ゲートウェイの３者
間での取引となるが、サーバ管理型ウォレットは、利用
者のクライアントソフトヘの処理負担を軽減するため、
一般にネットワーク上に設置したサーバ上で動作するソ
フトである。現在、発表されているサーバ管理型ウォレ
ットは、従来技術２に相当し、利用者が入力した銀行口
座の暗証番号（ＰＩＮ）をサーバウォレットの動作する
サーバで見ることができてしまう。利用者とサーバ管理
型ウォレット間で暗号化したとしても、加盟店に送信す
る電文を作成するために、一度復号化することになる。

【００９１】そこで、実施の形態の５で説明したシステ
ムをネットワークデビット決済用サーバ管理型ウォレッ
トに適用する。以下、本実施の形態のシステムの動作を
図８、図９を用いて説明する。図８、図９において、Ｐ
ＧＷは銀行サーバ（サービスプロバイダ）、Ｍは加盟
店、ＳＷはサーバウォレット（認証代行サーバ装置）、
ＡＳは認証サーバ（クライアントＣと認証代行サーバ間
の認証用）である。

【００９２】まず、図８に示すように、利用者がＩＣカ
ードをクライアントＣに挿入して、クライアントＣの支
払いボタンを押すと、加盟店Ｍから取引開始を示すイニ
シエーションがクライアントＣに送られる。続いて、利
用者がカードパスワードを入力すると、認証サーバＡＳ
によってＩＣカードの認証が行われる。認証後、クライ
アントＣは、認証サーバＡＳに対してサービスログイン
を要求する。これにより、サービスが起動する。

【００９３】サービス起動後、サーバウォレットＳＷか
ら利用者の口座を問い合わせるメニューが送られる。利
用者は、クライアントＣを操作して所望の口座を指定す
る。利用者の口座を指定する情報がサーバウォレットＳ
Ｗに送られると、サーバウォレットＳＷは、銀行サーバ
ＰＧＷとの間で所定の初期化処理を行う。

【００９４】次に、図９に示すように、サーバウォレッ
トＳＷは、口座情報とＰＧＷ公開鍵（暗号用公開鍵Ｐｋ
ＳＰ−Ａ，ＰｋＳＰ−Ｂに相当）とその他の情報（ＳＥ
Ｔ／ＳＥＣＥではＰＩＨｅａｄ）とをクライアントＣへ
送信する。利用者は、ＰＩＮ（暗証番号、すなわち実施
の形態の５の認証情報Ａ，Ｂに相当）をクライアントＣ
に入力する。ここで、ＳＥＴ／ＳＥＣＥでは、ＰＡＮＤ
ａｔａと呼ばれる領域に、ＰＩＮあるいはＰＩＮのデー
タフォーマットを変換したものが含まれるため、これを
クライアントＣにおいて組み立てる。

【００９５】そして、ＰＩＮ情報は、サービスプロバイ
ダである銀行サーバＰＧＷにのみ通知し、サーバウォレ
ットＳＷに対しては秘匿するために、クライアントＣに
おいてＰＩＮ関連暗号データＨ（ＰＩＨｅａｄ＋ＰＡＮ
Ｄａｔａ）、Ｈ（ＰＡＮＤａｔａ）、Ｅ（ＰｋＰＧＷ，
ＰＡＮＤａｔａ＋Ｋ）を計算する。ここでのＨ（）はハ
ッシュ演算を示し、Ｅ（）はＲＳＡ演算を示す。こうし
て、ＰＧＷ公開鍵で暗号化されたＰＩＮ情報が銀行サー
バＰＧＷに送られる。

【００９６】サーバウォレットＳＷから加盟店Ｍへの電
文については、通常のクライアントＣからの電文、ある
いは従来のサーバ管理型ウォレットからの電文フォーマ
ットと合わせることで加盟店Ｍ、及び銀行サーバＳＷは
従来どおりの機能のままで良い。

【００９７】これにより、銀行口座ＰＩＮはサーバウォ
レット事業者では解読困難となり、銀行口座ＰＩＮが漏
洩するリスクを減少させることができる。また、金融機
関が利用者をＰＩＮによって直接認証する手段をもつこ
とにより、不正などが発生した場合の金融機関、サーバ
ウォレット事業者、利用者間の責任所在の明確化が容易
になる。なお、本実施の形態では、認証代行サーバを利
用しない場合のクライアントと加盟店、加盟店と銀行サ
ーバ間の電文には変更を加えないことが可能になってい
る。

【００９８】また、本実施の形態では、利用者にはスマ
ートカードを配布し、クライアントとサーバウォレット
事業者サーバ間の相互認証に利用することを想定してい
る。ＳＳＬ（Secure Sockets Layer）サーバ認証、ある
いは、クライアント認証書をハードディスク上に格納し
た形態でのＳＳＬ相互認証を用いても構わない。しか
し、一般に偽造が困難なスマートカードを利用すること
により、仮に銀行口座ＰＩＮが利用者の管理ミスで他人
に漏洩した場合にも、スマートカードのコピーや盗難が
無い限りには、なりすまして決済を行われてしまうリス
クは少なくなる。また、本発明のクライアントＣに相当
するものとして上記スマートカードを利用した場合に
は、ＰＩＮ関連の処理のほとんどをスマートカード内で
実行することになり、端末の共同利用などを考えた場合
に、より安全性を向上させることが可能である。

【００９９】［実施の形態の９］図１０は本発明の第９
の実施の形態となる認証代行サービスシステムの動作を
示すシーケンス図である。本実施の形態の認証代行サー
ビスシステムは、実施の形態の５で説明したシステムを
ネットワークデビット決済におけるサーバ管理型ウォレ
ットの顧客証明書取得に適用したものである。

【０１００】なお、図１０では、クライアントＣとサー
バウォレットＳＷ間の認証などシーケンス前半部分につ
いては、実施の形態の８と基本的に同一なため省略す
る。ＳＥＣＥなどにおいては、顧客証明書を顧客認証局
に申請する以前に金融機関などから顧客特定暗証番号を
郵送などにより入手しておく。これを顧客認証局への申
請時に申請書内に記述し、顧客認証局はこの正当性を審
査項目の一つとする。つまり、顧客認証局は、この顧客
特定暗証番号により顧客の認証を行っていることになる
（もちろん、この番号のみで認証しているわけではな
く、申請書の記述内容のチェックなども併せて行う）。

【０１０１】従来のサーバ管理型ウォレットでは、実施
の形態の８と同様に顧客特定暗証番号のサーバウォレッ
ト事業者への漏洩の問題がある。例えば、サーバウォレ
ット事業者の運用者がこれを盗難し、顧客になりすまし
た場合、顧客秘密鍵、及び対応する証明書の更新がなさ
れ、なりすましてデビット決済を実行される恐れがあ
る。

【０１０２】そこで、実施の形態の５で説明したシステ
ムをネットワークデビット決済用サーバ管理型ウォレッ
トに適用する。以下、本実施の形態のシステムの動作を
図１０を用いて説明する。図１０において、ＣＣＡは顧
客認証局である。まず、サーバウォレットＳＷは、申請
書を顧客認証局ＣＣＡに要求して取得する。そして、サ
ーバウォレットＳＷは、この申請書と共にＣＣＡ公開鍵
（暗号用公開鍵ＰｋＳＰ−Ａ，ＰｋＳＰ−Ｂに相当）を
クライアントＣへ送信する。

【０１０３】利用者は、顧客特定暗証番号をクライアン
トＣに入力する。クライアントＣは、この顧客特定暗証
番号をＣＣＡ公開鍵を用いて暗号化し、暗号化された情
報をサーバウォレットＳＷへ送信する。サーバウォレッ
トＳＷは、クライアントＣからの情報に顧客署名を付与
した上で、顧客認証局ＣＣＡへ転送する。

【０１０４】顧客認証局ＣＣＡは、サーバウォレットＳ
Ｗから受け取った暗号化された情報をＣＣＡ秘密鍵で復
号化して、顧客特定暗証番号を取得し、この顧客特定暗
証番号を基に利用者の認証を行う。認証後、顧客認証局
ＣＣＡは、証明書をサーバウォレットＳＷへ送信する。

【０１０５】以上のように、顧客特定暗証番号を暗号化
して送信するため、サーバウォレット事業者での解読は
困難になる。サーバウォレット事業者によるリプレイ攻
撃を防ぐためには、顧客特定暗証番号に加えてシリアル
番号など申請の度に異なる値を暗号化対象に含めること
が望ましい。なお、本実施の形態の場合は、平成１１年
９月現在公開されているＳＥＣＥ仕様における顧客認証
局ＣＣＡの機能に加えて、顧客認証局暗号化用秘密鍵に
よる顧客特定暗証番号の復号化機能が顧客認証局ＣＣＡ
に新たに必要になる。

【０１０６】［実施の形態の１０］図１１、図１２は本
発明の第１０の実施の形態となる認証代行サービスシス
テムの動作を示すシーケンス図である。本実施の形態の
認証代行サービスシステムは、実施の形態の３で説明し
たシステムをＳＳＬ認証の認証代行サーバとして適用し
たものである。本実施の形態は、ＳＳＬ相互認証を行う
ものであり、暗号化アルゴリズムはＲＳＡを想定してい
る。

【０１０７】クライアントとＳＳＬサーバの間で、従来
のＳＳＬ認証を行う場合、クライアントには利用者の証
明書・秘密鍵などの秘密情報が必要となる。前述の通
り、利用者の秘密情報管理にはコスト・リスク等が伴う
ことが多いので、利用者の秘密情報をできるだけ少なく
するために、認証代行サーバを利用するとする。ところ
が、全てのＳＳＬ認証を認証代行サーバで行わせるとな
ると、ＳＳＬの暗号化情報全てを、クライアントの代わ
りに認証代行サーバーで作成することになるので、ＳＳ
Ｌサーバとクライアント間の共通鍵を認証代行サーバで
作成することが可能となる。これでは、認証代行サーバ
ーにすべての秘密情報が漏れてしまう。

【０１０８】そこで、実施の形態の３を適用すると、Ｓ
ＳＬサーバとクライアント間で持つ、秘密情報の元とな
るプリマスターシークレット及びマスターシークレット
の生成についてはクライアントで行わせ、プリマスター
シークレットについては認証代行サーバで見ることがで
きないように、通信時にはＳＳＬサーバの公開鍵で暗号
化し、認証代行サーバに転送する。また、ＳＳＬサーバ
から要求されるクライアントの署名については、そのダ
イジェストをクライアントで作成し、認証代行サーバに
転送し、認証代行サーバが利用者の秘密鍵で署名を施
す。こうすることにより、認証代行サーバに利用者の秘
密情報が漏れることなく、ＳＳＬ認証が可能となる。

【０１０９】以下、本実施の形態のシステムの動作を図
１１、図１２を用いて説明する。まず、図１１に示すよ
うに、利用者がＩＣカードをクライアントＣに挿入し、
カードパスワードを入力すると、認証代行サーバＳによ
ってＩＣカードの認証が行われる。認証後、クライアン
トＣは、認証代行サーバＳに対してサービスログインを
要求する。これにより、サービスが起動する。

【０１１０】サービス起動後、認証代行サーバＳは、Ｓ
ＳＬサーバとの間で所定の初期化処理を行う。次に、図
１２に示すように、認証代行サーバＳは、クライアント
Ｃに対してクライアントキー（Client Key）を要求する
と共に、サーバ公開鍵（暗号用公開鍵ＰｋＳＰ−Ａ，Ｐ
ｋＳＰ−Ｂに相当）をクライアントＣへ送信する。

【０１１１】クライアントＣは、プリマスターシークレ
ット（データＳｄＳＳＫＡ，ＳｄＳＳｋＢに相当）を生
成して、このプリマスターシークレットをサーバ公開鍵
を用いて暗号化し、暗号化された情報を認証代行サーバ
Ｓへ送信する。こうして、サーバ公開鍵で暗号化された
プリマスターシークレットがＳＳＬサーバに送られる。
さらに、クライアントＣは、プリマスターシークレット
を基にマスターシークレットを生成して、このマスター
シークレットに対してハッシュ演算を行い、このハッシ
ュ演算を行った情報を認証代行サーバＳへ送信する。

【０１１２】以上のように、ＳＳＬ認証におけるほとん
どの部分を認証代行サーバＳで行うことができるが、認
証代行サーバＳに対して利用者が秘密にしておきたい部
分であるプリマスターシークレット、マスターシークレ
ットを生成する部分については、認証代行サーバＳから
必要情報を与えることにより、クライアントＣで生成で
きる。

【０１１３】それ以外の部分については、認証代行サー
バＳがＳＳＬサーバとの通信をすべて肩代わりする。図
１２に示す「Ｆｉｎｉｓｈｅｄ」の部分をクライアント
Ｃに送ることにより、双方向での暗号化通信（実施の形
態の３で説明したセッションキーを用いた暗号化通信に
相当）が開始できる。その通信においては、認証代行サ
ーバＳは、ＳＳＬサーバとクライアントＣで持っている
共通鍵を知ることが無いので、通信内容が漏洩すること
なく、ＳＳＬサーバとクライアントＣ間で通信が可能で
ある。

【０１１４】

【発明の効果】本発明によれば、認証代行サーバ装置
が、所望のサービスに対応したサービスプロバイダ装置
の暗号用公開鍵をクライアント装置へ配送し、クライア
ント装置から受け取った暗号化された情報をサービスプ
ロバイダ装置へ転送し、クライアント装置が、サービス
プロバイダ装置へ送信すべき情報を暗号用公開鍵を用い
て暗号化し、この暗号化された情報を認証代行サーバ装
置へ送信し、サービスプロバイダ装置が、認証代行サー
バ装置から受け取った暗号化された情報を暗号用秘密鍵
を用いて復号化することにより、認証代行サーバ装置に
は漏洩することなく、クライアント装置からサービスプ
ロバイダ装置への情報転送を行うことができる。

【０１１５】また、認証代行サーバ装置が、所望のサー
ビスに対応したサービスプロバイダ装置に対して、クラ
イアント装置の暗号用公開鍵を配送し、サービスプロバ
イダ装置から受け取った暗号化された情報をクライアン
ト装置へ転送し、サービスプロバイダ装置が、クライア
ント装置へ送信すべき情報を暗号用公開鍵を用いて暗号
化し、この暗号化された情報を認証代行サーバ装置へ送
信し、クライアント装置が、認証代行サーバ装置から受
け取った暗号化された情報を暗号用秘密鍵を用いて復号
化することにより、認証代行サーバ装置には漏洩するこ
となく、サービスプロバイダ装置からクライアント装置
への情報転送を行うことができる。

【０１１６】また、認証代行サーバ装置が、所望のサー
ビスに対応したサービスプロバイダ装置の暗号用公開鍵
をクライアント装置へ配送し、クライアント装置から受
け取った暗号化された情報をサービスプロバイダ装置へ
転送し、サービスプロバイダ装置から受け取った暗号化
された情報をクライアント装置へ転送し、クライアント
装置が、サービスプロバイダ装置との間の暗号通信用セ
ッションキーあるいはこのセッションキーの元となるデ
ータを生成し、セッションキーあるいはデータを暗号用
公開鍵を用いて暗号化し、この暗号化された情報を認証
代行サーバ装置へ送信した後、サービスプロバイダ装置
へ送信すべき情報をセッションキーを用いて暗号化し、
この暗号化された情報を認証代行サーバ装置へ送信し、
サービスプロバイダ装置が、認証代行サーバ装置から受
け取った暗号化された情報を暗号用秘密鍵を用いて復号
化してセッションキーを取得し、あるいは暗号用秘密鍵
を用いた復号化によりデータを取得して、このデータか
らセッションキーを生成した後、クライアント装置へ送
信すべき情報をセッションキーを用いて暗号化し、この
暗号化された情報を認証代行サーバ装置へ送信すること
により、認証代行サーバ装置には漏洩することなく、ク
ライアント装置とサービスプロバイダ装置間の双方向の
情報転送を行うことができる。

【０１１７】また、認証代行サーバ装置が、暗号用公開
鍵をクライアント装置へ配送する際に、暗号用公開鍵と
共に暗号用公開鍵証明書を配送し、クライアント装置
が、暗号用公開鍵を用いた暗号化を行う前に、認証代行
サーバ装置から受け取った暗号用公開鍵証明書を基に暗
号用公開鍵を検証するので、認証代行サーバ装置から配
送される暗号用公開鍵を検証することができる。

【０１１８】また、クライアント装置が、暗号化を行う
際に、自装置の認証情報を暗号用公開鍵を用いて暗号化
し、この暗号化された情報を認証代行サーバ装置へ送信
し、サービスプロバイダ装置が、復号化を行う際に、認
証代行サーバ装置から受け取った暗号化された情報を暗
号用秘密鍵を用いて復号化して認証情報を取得し、この
認証情報を基にクライアント装置の認証を行うので、認
証代行サーバ装置がクライアント装置になりすますこと
を防ぐことができ、さらに認証代行サーバ装置の責任を
軽減させることが可能となる。

【図面の簡単な説明】

【図１】 本発明の第１の実施の形態となる認証代行サ
ービスシステムの構成を示すブロック図である。

【図２】 本発明の第２の実施の形態となる認証代行サ
ービスシステムの構成を示すブロック図である。

【図３】 本発明の第３の実施の形態となる認証代行サ
ービスシステムの構成を示すブロック図である。

【図４】 本発明の第４の実施の形態となる認証代行サ
ービスシステムの構成を示すブロック図である。

【図５】 本発明の第５の実施の形態となる認証代行サ
ービスシステムの構成を示すブロック図である。

【図６】 本発明の第６の実施の形態となる認証代行サ
ーバ装置の構成を示すブロック図である。

【図７】 本発明の第７の実施の形態となるクライアン
ト装置の構成を示すブロック図である。

【図８】 本発明の第８の実施の形態となる認証代行サ
ービスシステムの動作を示すシーケンス図である。

【図９】 本発明の第８の実施の形態となる認証代行サ
ービスシステムの動作を示すシーケンス図である。

【図１０】 本発明の第９の実施の形態となる認証代行
サービスシステムの動作を示すシーケンス図である。

【図１１】 本発明の第１０の実施の形態となる認証代
行サービスシステムの動作を示すシーケンス図である。

【図１２】 本発明の第１０の実施の形態となる認証代
行サービスシステムの動作を示すシーケンス図である。

【図１３】 従来のシステムの１例を示すブロック図で
ある。

【図１４】 従来のシステムの他の例を示すブロック図
である。

【図１５】 従来のシステムの他の例を示すブロック図
である。

【図１６】 従来技術１の構成を示すブロック図であ
る。

【図１７】 従来技術２の構成を示すブロック図であ
る。

【図１８】 従来技術３の構成を示すブロック図であ
る。

【符号の説明】

Ｃ…クライアント装置、Ｓ…認証代行サーバ装置、ＳＰ
−Ａ、ＳＰ−Ｂ…サービスプロバイダ装置。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 安田 仁 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 (72)発明者 山本 守孝 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 (72)発明者 桑田 晶彦 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 (72)発明者 今泉 法子 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 (72)発明者 嶋崎 剛 東京都千代田区内幸町一丁目１番６号 エ ヌ・ティ・ティ・コミュニケーションズ株 式会社内 Ｆターム(参考） 5B085 AE13 AE23 AE29 BG07 5B089 GA19 GA21 JA32 JB22 KA17 KB13 KC58 KH30

Claims (16)

【特許請求の範囲】
1. 【請求項１】 サービスを提供するサービスプロバイダ
   装置とサービス提供を受けるクライアント装置との間に
   設けられた認証代行サーバ装置が前記クライアント装置
   に代わって前記サービスプロバイダ装置から認証を受け
   る認証代行方法において、 サービス提供時、所望のサービスに対応した前記サービ
   スプロバイダ装置の暗号用公開鍵を前記認証代行サーバ
   装置から前記クライアント装置へ配送する手順と、 前記クライアント装置において前記サービスプロバイダ
   装置へ送信すべき情報を前記認証代行サーバ装置から受
   け取った暗号用公開鍵を用いて暗号化し、この暗号化さ
   れた情報を前記認証代行サーバ装置へ送信する手順と、 前記クライアント装置から受け取った暗号化された情報
   を前記認証代行サーバ装置から前記サービスプロバイダ
   装置へ転送する手順と、 前記サービスプロバイダ装置において前記認証代行サー
   バ装置から受け取った暗号化された情報を暗号用秘密鍵
   を用いて復号化する手順とを有し、認証代行サーバ装置
   には漏洩することなく、クライアント装置からサービス
   プロバイダ装置への情報転送を行うことを特徴とする認
   証代行方法。
2. 【請求項２】 サービスを提供するサービスプロバイダ
   装置とサービス提供を受けるクライアント装置との間に
   設けられた認証代行サーバ装置が前記クライアント装置
   に代わって前記サービスプロバイダ装置から認証を受け
   る認証代行方法において、 サービス提供時、所望のサービスに対応した前記サービ
   スプロバイダ装置に対して、前記クライアント装置の暗
   号用公開鍵を前記認証代行サーバ装置から配送する手順
   と、 前記サービスプロバイダ装置において前記クライアント
   装置へ送信すべき情報を前記認証代行サーバ装置から受
   け取った暗号用公開鍵を用いて暗号化し、この暗号化さ
   れた情報を前記認証代行サーバ装置へ送信する手順と、 前記サービスプロバイダ装置から受け取った暗号化され
   た情報を前記認証代行サーバ装置から前記クライアント
   装置へ転送する手順と、 前記クライアント装置において前記認証代行サーバ装置
   から受け取った暗号化された情報を暗号用秘密鍵を用い
   て復号化する手順とを有し、認証代行サーバ装置には漏
   洩することなく、サービスプロバイダ装置からクライア
   ント装置への情報転送を行うことを特徴とする認証代行
   方法。
3. 【請求項３】 サービスを提供するサービスプロバイダ
   装置とサービス提供を受けるクライアント装置との間に
   設けられた認証代行サーバ装置が前記クライアント装置
   に代わって前記サービスプロバイダ装置から認証を受け
   る認証代行方法において、 サービス提供時、所望のサービスに対応した前記サービ
   スプロバイダ装置の暗号用公開鍵を前記認証代行サーバ
   装置から前記クライアント装置へ配送する手順と、 前記クライアント装置において前記サービスプロバイダ
   装置との間の暗号通信用セッションキーあるいはこのセ
   ッションキーの元となるデータを生成し、前記セッショ
   ンキーあるいはデータを前記認証代行サーバ装置から受
   け取った暗号用公開鍵を用いて暗号化し、この暗号化さ
   れた情報を前記認証代行サーバ装置へ送信する手順と、 前記クライアント装置から受け取った暗号化された情報
   を前記認証代行サーバ装置から前記サービスプロバイダ
   装置へ転送する手順と、 前記サービスプロバイダ装置において前記認証代行サー
   バ装置から受け取った暗号化された情報を暗号用秘密鍵
   を用いて復号化して前記セッションキーを取得し、ある
   いは暗号用秘密鍵を用いた復号化により前記データを取
   得して、このデータから前記セッションキーを生成する
   手順と、 前記クライアント装置あるいは前記サービスプロバイダ
   装置において送信すべき情報を前記セッションキーを用
   いて暗号化し、この暗号化された情報を前記認証代行サ
   ーバ装置へ送信する手順と、 前記セッションキーを用いて暗号化された情報を前記認
   証代行サーバ装置から前記サービスプロバイダ装置ある
   いは前記クライアント装置へ転送する手順と、 前記セッションキーを用いて暗号化された情報を前記サ
   ービスプロバイダ装置あるいは前記クライアント装置に
   おいて自身が有する前記セッションキーを用いて復号化
   する手順とを有し、認証代行サーバ装置には漏洩するこ
   となく、クライアント装置とサービスプロバイダ装置間
   の双方向の情報転送を行うことを特徴とする認証代行方
   法。
4. 【請求項４】 請求項１または３記載の認証代行方法に
   おいて、 前記暗号用公開鍵を前記認証代行サーバ装置から前記ク
   ライアント装置へ配送する際に、前記暗号用公開鍵と共
   に暗号用公開鍵証明書を配送する手順と、 前記クライアント装置において前記暗号用公開鍵を用い
   た暗号化を行う前に、前記認証代行サーバ装置から受け
   取った暗号用公開鍵証明書を基に前記暗号用公開鍵を検
   証する手順とを有することを特徴とする認証代行方法。
5. 【請求項５】 請求項１または３記載の認証代行方法に
   おいて、 前記クライアント装置において暗号化を行う際に、この
   クライアント装置の認証情報を前記暗号用公開鍵を用い
   て暗号化し、この暗号化された情報を前記認証代行サー
   バ装置へ送信する手順と、 前記サービスプロバイダ装置において復号化を行う際
   に、前記認証代行サーバ装置から受け取った暗号化され
   た情報を暗号用秘密鍵を用いて復号化して前記認証情報
   を取得し、この認証情報を基に前記クライアント装置の
   認証を行う手順とを有することを特徴とする認証代行方
   法。
6. 【請求項６】 サービスを提供するサービスプロバイダ
   装置と、前記サービスプロバイダ装置と接続された、サ
   ービス提供を受けるクライアント装置と、前記サービス
   プロバイダ装置とクライアント装置との間に設けられた
   認証代行サーバ装置とからなり、前記認証代行サーバ装
   置が前記クライアント装置に代わって前記サービスプロ
   バイダ装置から認証を受ける認証代行サービスシステム
   において、 前記認証代行サーバ装置は、サービス提供時、所望のサ
   ービスに対応した前記サービスプロバイダ装置の暗号用
   公開鍵を前記クライアント装置へ配送し、前記クライア
   ント装置から受け取った暗号化された情報を前記サービ
   スプロバイダ装置へ転送する手段を有し、 前記クライアント装置は、前記サービスプロバイダ装置
   へ送信すべき情報を前記認証代行サーバ装置から受け取
   った暗号用公開鍵を用いて暗号化し、この暗号化された
   情報を前記認証代行サーバ装置へ送信する手段を有し、 前記サービスプロバイダ装置は、前記認証代行サーバ装
   置から受け取った暗号化された情報を暗号用秘密鍵を用
   いて復号化する手段を有し、認証代行サーバ装置には漏
   洩することなく、クライアント装置からサービスプロバ
   イダ装置への情報転送を行うことを特徴とする認証代行
   サービスシステム。
7. 【請求項７】 サービスを提供するサービスプロバイダ
   装置と、前記サービスプロバイダ装置と接続された、サ
   ービス提供を受けるクライアント装置と、前記サービス
   プロバイダ装置とクライアント装置との間に設けられた
   認証代行サーバ装置とからなり、前記認証代行サーバ装
   置が前記クライアント装置に代わって前記サービスプロ
   バイダ装置から認証を受ける認証代行サービスシステム
   において、 前記認証代行サーバ装置は、サービス提供時、所望のサ
   ービスに対応した前記サービスプロバイダ装置に対し
   て、前記クライアント装置の暗号用公開鍵を配送し、前
   記サービスプロバイダ装置から受け取った暗号化された
   情報を前記クライアント装置へ転送する手段を有し、 前記サービスプロバイダ装置は、前記クライアント装置
   へ送信すべき情報を前記認証代行サーバ装置から受け取
   った暗号用公開鍵を用いて暗号化し、この暗号化された
   情報を前記認証代行サーバ装置へ送信する手段を有し、 前記クライアント装置は、前記認証代行サーバ装置から
   受け取った暗号化された情報を暗号用秘密鍵を用いて復
   号化する手段を有し、認証代行サーバ装置には漏洩する
   ことなく、サービスプロバイダ装置からクライアント装
   置への情報転送を行うことを特徴とする認証代行サービ
   スシステム。
8. 【請求項８】 サービスを提供するサービスプロバイダ
   装置と、前記サービスプロバイダ装置と接続された、サ
   ービス提供を受けるクライアント装置と、前記サービス
   プロバイダ装置とクライアント装置との間に設けられた
   認証代行サーバ装置とからなり、前記認証代行サーバ装
   置が前記クライアント装置に代わって前記サービスプロ
   バイダ装置から認証を受ける認証代行サービスシステム
   において、 前記認証代行サーバ装置は、サービス提供時、所望のサ
   ービスに対応した前記サービスプロバイダ装置の暗号用
   公開鍵を前記クライアント装置へ配送し、前記クライア
   ント装置から受け取った暗号化された情報を前記サービ
   スプロバイダ装置へ転送し、前記サービスプロバイダ装
   置から受け取った暗号化された情報を前記クライアント
   装置へ転送する手段を有し、 前記クライアント装置は、前記サービスプロバイダ装置
   との間の暗号通信用セッションキーあるいはこのセッシ
   ョンキーの元となるデータを生成し、前記セッションキ
   ーあるいはデータを前記認証代行サーバ装置から受け取
   った暗号用公開鍵を用いて暗号化し、この暗号化された
   情報を前記認証代行サーバ装置へ送信した後、前記サー
   ビスプロバイダ装置へ送信すべき情報を前記セッション
   キーを用いて暗号化し、この暗号化された情報を前記認
   証代行サーバ装置へ送信する手段を有し、 前記サービスプロバイダ装置は、前記認証代行サーバ装
   置から受け取った暗号化された情報を暗号用秘密鍵を用
   いて復号化して前記セッションキーを取得し、あるいは
   暗号用秘密鍵を用いた復号化により前記データを取得し
   て、このデータから前記セッションキーを生成した後、
   前記クライアント装置へ送信すべき情報を前記セッショ
   ンキーを用いて暗号化し、この暗号化された情報を前記
   認証代行サーバ装置へ送信する手段を有し、認証代行サ
   ーバ装置には漏洩することなく、クライアント装置とサ
   ービスプロバイダ装置間の双方向の情報転送を行うこと
   を特徴とする認証代行サービスシステム。
9. 【請求項９】 請求項６または８記載の認証代行サービ
   スシステムにおいて、 前記認証代行サーバ装置は、前記暗号用公開鍵を前記ク
   ライアント装置へ配送する際に、前記暗号用公開鍵と共
   に暗号用公開鍵証明書を配送する手段を有し、 前記クライアント装置は、前記暗号用公開鍵を用いた暗
   号化を行う前に、前記認証代行サーバ装置から受け取っ
   た暗号用公開鍵証明書を基に前記暗号用公開鍵を検証す
   る手段を有することを特徴とする認証代行サービスシス
   テム。
10. 【請求項１０】 請求項６または８記載の認証代行サー
    ビスシステムにおいて、 前記クライアント装置は、前記暗号化を行う際に、自装
    置の認証情報を前記暗号用公開鍵を用いて暗号化し、こ
    の暗号化された情報を前記認証代行サーバ装置へ送信す
    る手段を有し、 前記サービスプロバイダ装置は、前記復号化を行う際
    に、前記認証代行サーバ装置から受け取った暗号化され
    た情報を暗号用秘密鍵を用いて復号化して前記認証情報
    を取得し、この認証情報を基に前記クライアント装置の
    認証を行う手段を有することを特徴とする認証代行サー
    ビスシステム。
11. 【請求項１１】 サービスを提供するサービスプロバイ
    ダ装置とサービス提供を受けるクライアント装置との間
    に設けられ、前記クライアント装置に代わって前記サー
    ビスプロバイダ装置から認証を受ける認証代行サーバ装
    置において、 前記認証代行サーバ装置は、サービス提供時、所望のサ
    ービスに対応した前記サービスプロバイダ装置の暗号用
    公開鍵を前記クライアント装置へ配送し、この暗号用公
    開鍵を用いて暗号化された情報を前記クライアント装置
    から受け取り、暗号用秘密鍵を用いた復号化を行わせる
    べく、前記暗号化された情報を前記サービスプロバイダ
    装置へ転送する手段を有することを特徴とする認証代行
    サーバ装置。
12. 【請求項１２】 サービスを提供するサービスプロバイ
    ダ装置とサービス提供を受けるクライアント装置との間
    に設けられ、前記クライアント装置に代わって前記サー
    ビスプロバイダ装置から認証を受ける認証代行サーバ装
    置において、 前記認証代行サーバ装置は、サービス提供時、所望のサ
    ービスに対応した前記サービスプロバイダ装置に対し
    て、前記クライアント装置の暗号用公開鍵を配送し、こ
    の暗号用公開鍵を用いて暗号化された情報を前記サービ
    スプロバイダ装置から受け取り、暗号用秘密鍵を用いた
    復号化を行わせるべく、前記暗号化された情報を前記ク
    ライアント装置へ転送する手段を有することを特徴とす
    る認証代行サーバ装置。
13. 【請求項１３】 サービスを提供するサービスプロバイ
    ダ装置とサービス提供を受けるクライアント装置との間
    に設けられ、前記クライアント装置に代わって前記サー
    ビスプロバイダ装置から認証を受ける認証代行サーバ装
    置において、 前記認証代行サーバ装置は、サービス提供時、所望のサ
    ービスに対応した前記サービスプロバイダ装置の暗号用
    公開鍵を前記クライアント装置へ配送し、この暗号用公
    開鍵を用いて暗号化された暗号通信用セッションキーあ
    るいはこのセッションキーの元となるデータを前記クラ
    イアント装置から受け取り、暗号用秘密鍵を用いた復号
    化を行わせるべく、前記暗号化されたセッションキーあ
    るいはデータを前記サービスプロバイダ装置へ転送した
    後、前記セッションキーを用いて暗号化された、前記ク
    ライアント装置からの情報を前記サービスプロバイダ装
    置へ転送すると共に、前記セッションキーを用いて暗号
    化された、前記サービスプロバイダ装置からの情報を前
    記クライアント装置へ転送する手段を有することを特徴
    とする認証代行サーバ装置。
14. 【請求項１４】 請求項１１または１３記載の認証代行
    サーバ装置において、 前記認証代行サーバ装置は、前記クライアント装置に前
    記暗号用公開鍵の検証を行わせるべく、前記暗号用公開
    鍵と共に暗号用公開鍵証明書を前記クライアント装置へ
    配送する手段を有することを特徴とする認証代行サーバ
    装置。
15. 【請求項１５】 サービスを提供するサービスプロバイ
    ダ装置とサービス提供を受けるクライアント装置との間
    に設けられた認証代行サーバ装置が前記クライアント装
    置に代わって前記サービスプロバイダ装置から認証を受
    ける認証代行サービスシステムにおける前記クライアン
    ト装置であって、 前記認証代行サーバ装置からクライアント認証を受ける
    ための署名を生成する署名生成手段を備えたＩＣカード
    からなると共に、 前記サービスプロバイダ装置へ送信すべき情報を暗号用
    公開鍵を用いて暗号化する暗号化手段と、前記ＩＣカー
    ドによって生成された署名を前記認証代行サーバ装置へ
    送信し、前記認証代行サーバ装置から送信された暗号用
    公開鍵を受け取って前記暗号化手段へ出力し、前記暗号
    化手段によって暗号化された情報を前記認証代行サーバ
    装置へ送信する送受信手段とを備えた処理装置からなる
    ことを特徴とするクライアント装置。
16. 【請求項１６】 サービスを提供するサービスプロバイ
    ダ装置とサービス提供を受けるクライアント装置との間
    に設けられた認証代行サーバ装置が前記クライアント装
    置に代わって前記サービスプロバイダ装置から認証を受
    ける認証代行サービスシステムにおける前記クライアン
    ト装置であって、 前記認証代行サーバ装置からクライアント認証を受ける
    ための署名を生成する署名生成手段と、前記サービスプ
    ロバイダ装置へ送信すべき情報を暗号用公開鍵を用いて
    暗号化する暗号化手段とを備えたＩＣカードからなると
    共に、 前記ＩＣカードによって生成された署名を前記認証代行
    サーバ装置へ送信し、前記認証代行サーバ装置から送信
    された暗号用公開鍵を受け取って前記ＩＣカードへ出力
    し、前記ＩＣカードによって暗号化された情報を前記認
    証代行サーバ装置へ送信する送受信手段とを備えた処理
    装置からなることを特徴とするクライアント装置。