JP4730814B2

JP4730814B2 - ユーザ情報管理方法およびシステム

Info

Publication number: JP4730814B2
Application number: JP2005137221A
Authority: JP
Inventors: 泰之渡邊; 慎司太田
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2005-05-10
Filing date: 2005-05-10
Publication date: 2011-07-20
Anticipated expiration: 2025-05-10
Also published as: JP2006319410A

Description

本発明は、ユーザ情報管理方法およびシステムに係り、特に、ユーザがサービス提供者へ登録する属性情報の管理に好適なユーザ情報管理方法およびシステムに関する。

サービスを提供するサーバがサービスの提供を受けるユーザを認証する手法として、ログイン名とパスワードとの一致を条件に認証するパスワード認証方式や、サーバとユーザ端末とが同一の暗号鍵を共有して認証を行う共通鍵認証方式が知られている。さらには、これらの方式よりも安全性の高い認証方式として、特許文献１には、サーバとユーザ端末とが個別の暗号鍵（公開鍵および秘密鍵）を用いて認証を行う公開鍵認証方式が開示されている。

このような認証手法において、多数のユーザの認証を効率よく安全に行うためには、認証に必要な情報を管理するシステム、すなわち認証基盤が必要となり、公開鍵認証方式では公開鍵認証基盤(PKI:Public Key Infrastructure)が用いられる。
特開２００３−３０９５４６号公報

ユーザが多種多様なサービスの提供を希望する場合、全てのサービス提供サーバに自身の氏名、年齢、性別、現住所、電話番号等の属性情報を登録し、さらには、サービス提供サーバごとに認証用のパスワードや共通鍵、あるいは公開鍵証明書を設定しなければならない。

しかしながら、このような登録方法ではパスワード、共通鍵あるいは公開鍵証明書の管理が煩雑になるのみならず、属性情報の一部が変更になると、全てのサービス提供サーバにおいて属性情報の変更手続きが必要となってしまう。また、一般的に情報が一元管理されていれば、その変更は容易になるので、上記した認証方法においても、ユーザの属性情報を第３のサーバで一元管理し、サービス提供サーバは、ユーザの属性情報が必要となったときのみ前記第３のサーバに属性情報の公開を求めるようなシステムも考えられる。

しかしながら、属性情報が単純に一元管理されてしまうと、前記第３のサーバが属性情報の公開を要求された場合に、公開範囲をサービス提供サーバごとに異ならせることが難しかった。

本発明の目的は、上記した従来技術の課題を解決し、ユーザの属性情報や認証用の情報を簡単に一元管理でき、かつ属性情報の開示範囲を開示相手に応じて柔軟に変更できる自由度の高いユーザ情報管理方法およびシステムを提供することにある。

上記した目的を達成するために、本発明は、ユーザ端末、前記ユーザ端末の要求に応答して公開鍵証明書を発行するユーザ管理システムおよび各ユーザ端末の要求に応答してサービスを提供する複数のサービス提供サーバを含むネットワーク上で、ユーザ管理システムが各ユーザの情報を一元管理するユーザ情報管理方法において、ユーザ端末がユーザ管理システムへ、ユーザの属性情報を含む登録要求を送信する手順と、ユーザ管理システムが前記登録要求に応答して、第１ユーザ識別子ならびに第１公開鍵および第１秘密鍵の暗号鍵ペアを生成する手順と、前記ユーザ管理システムが、前記第１公開鍵に関する公開鍵証明書を生成する手順と、前記ユーザ管理システムが、前記第１ユーザ識別子、第１公開鍵、第１秘密鍵、公開鍵証明書および属性情報を相互に対応付けて記憶する手順と、前記ユーザ管理システムがユーザ端末へ、前記第１ユーザ識別子、第１公開鍵、第１秘密鍵および公開鍵証明書を送信する手順と、前記ユーザ端末が、第２ユーザ識別子ならびに第２公開鍵および第２秘密鍵の暗号鍵ペアを生成する手順と、前記ユーザ端末が、前記第２公開鍵に関して代理証明書を発行する手順と、前記ユーザ端末が前記サービス提供サーバへ、前記代理証明書を含むサービス要求を送信する手順と、前記サービス提供サーバが前記ユーザ管理システムへ、前記代理証明書を含む属性情報要求を送信する手段と、前記ユーザ管理システムが前記サービス提供サーバを認証する手順と、前記ユーザ管理システムが、受信した代理証明書に基づいて属性情報を検索し、検索結果を前記サービス提供サーバへ送信する手順とを含むことを特徴とする。

本発明によれば、以下のような効果が達成される。
(1)ユーザがサービスの提供を受けるために各サービス提供サーバへ登録すべき属性情報が、ユーザ管理システムに登録されて一括管理されている。したがって、属性情報の一部を変更する場合でも、ユーザ管理システムに登録されている属性情報のみを変更すれば、この変更が各サービス提供サーバへ公開される属性情報に反映されるようになる。
(2)各サービス提供サーバによるユーザの認証が公開鍵認証方式により行われるので、安全性の高い認証が可能になる。
(3)公開対象の属性情報を公開先のサービス提供サーバに応じて異ならせることができるので、属性情報に関して自由度の高い公開が可能になる。

以下、図面を参照して本発明の最良の実施の形態について詳細に説明する。図１は、本発明に係るユーザ認証方法が適用されるユーザ認証システムの構成を示したブロック図であり、複数のサービス提供サーバ１（１ａ，１ｂ…）と、各サービス提供サーバ１を利用するユーザ端末２（２ａ，２ｂ…）と、認証局としての機能を備えるユーザ管理システム３とが、インターネット等の広域ネットワークを介して相互に接続されている。前記ユーザ管理システム３には、各ユーザの属性情報を一元管理するディレクトリ４が併設されている。

図２は、ユーザがユーザ端末２からユーザ管理システム３へユーザ登録を要求して暗号鍵ペアおよび公開鍵証明書を取得する手順を示したフローチャートであり、図３は、そのシーケンスフローである。ここでは、ユーザAが自身のユーザ端末２ａからユーザ登録を要求する場合を例にして説明する。

ユーザAは、ユーザ登録の要求に際して、自身の氏名、生年月日、性別、現住所およびその電話番号、ならびに勤務先およびその電話番号等の個人情報を属性情報としてユーザ端末２ａに登録し、これをユーザ登録要求メッセージと共にユーザ管理システム３へ送信する。ユーザ管理システム３では、ユーザ端末２ａから送信されたユーザ登録要求がステップＳ１０１で受信されると、ステップＳ１０２では、当該ユーザ登録要求に含まれる属性情報が抽出されて一時記憶される。ステップＳ１０３では、当該ユーザAに対して一意のユーザ識別子IDaが割り当てられる。ステップＳ１０４では、当該ユーザAに固有の暗号鍵ペアとして、秘密鍵SKaおよび公開鍵PKaが生成される。ステップＳ１０５では、前記公開鍵PKaに対して公開鍵証明書PKCaが発行される。

公開鍵証明書(Public key Certificate：PKC)とは、公開鍵の所有者名（主体者）に関する情報、公開鍵データ、証明書の有効期間、証明書を発行した認証局情報などのデータを組み合わせたものに対して、認証局が電子署名を行って発行する証明書である。

図４は、本実施形態においてユーザAに発行される公開鍵証明書PKCaのフォーマットを示した図であり、シリアル番号(SNa)、所有者名(SUBJECTa)、発行者名(ISSUERa)、有効期限…およびユーザAに割り当てられた公開鍵PKaを含む各種の情報と、これらの情報に対してユーザ管理システム３が行った電子署名とが登録されている。本実施形態では、前記所有者名(SUBJECTa)として、前記ユーザ識別子IDaがCN（Common Name）として用いられ、これに発行者名(ISSUERa)が付与されたもの[CN(＝IDa)＋ISSUERa]が用いられる。

図２へ戻り、ステップＳ１０６では、前記ユーザ識別子IDa、暗号鍵ペア(SKa，PKa)および公開鍵証明書PKCaがユーザ端末２ａへ返信される。ステップＳ１０７では、前記ユーザ識別子IDa、暗号鍵ペア(SKa，PKa)、公開鍵証明書PKCaおよび前記ユーザAから提供された属性情報が、相互に対応付けられてディレクトリ４に記憶される。ステップＳ１０８において、前記ディレクトリ４から完了確認が受信されると、一連の公開鍵登録処理が終了する。

次いで、ユーザAがサービス提供サーバ１へアクセスし、認証手順を経てサービスの提供を受けるまでの手順について、図５、６のフローチャートおよび図７のシーケンスフローを参照して説明する。

ユーザAでは、いずれかのサービス提供サーバ１へアクセスする際に、図５のステップＳ２０１において任意のユーザ識別子IDanが生成され、さらに任意の秘密鍵SKanおよび公開鍵PKanの暗号鍵ペアが生成される。ステップＳ２０２では、前記公開鍵PKanに対して、前記公開鍵証明書PKCaの代理証明書PCanが、IETF RFC（Request for Comments）3820に基づいて発行される。ただし、発行者名、公開属性情報項目リスト、公開先リストの項目については下記に示す独自手順とする。

図８は、前記代理証明書PCanの内容を示した図であり、シリアル番号(SNan)、所有者名(SUBJECTan)、発行者名(ISSUERan)、認証局情報、公開属性情報項目リスト、公開先リスト…および前記公開鍵PKanを含む各種の情報と、これらの情報に対してユーザAが行った電子署名とが登録されている。

前記公開属性情報項目リストとは、前記ユーザAの属性情報のうち、前記サービス提供サーバに対して公開しても良いとユーザA自身により予め特定された属性情報のリストであり、公開先リストとは、前記リストに登録されている属性情報の公開が許可されるサービス提供サーバを特定するリストである。

なお、本実施形態では各ユーザが各サービス提供サーバの公開鍵証明書PKCbを予め取得しておき、前記公開先リストには、属性情報の公開を許可する全てのサービス提供サーバの公開鍵証明書PKCbの所有者名(SUBJECTb)を登録するものとし、この公開先リストはユーザ管理システムの公開鍵PKcで暗号化される。

このように、本実施形態ではユーザAによってユーザ管理サーバへ登録された属性情報の一部（まはた全部）が、予め限定された一部（または全部）のサービス提供サーバに対してのみ、その公開を許可される。

前記代理証明書PCanでは、前記公開鍵証明書PKCaの所有者(SUBJECTa＝[CN＋ISSUERa]）)))と当該代理証明書PCanのシリアル番号(SNan)とを連結し、これを予めユーザ管理システム３から提供されている公開鍵PKcで暗号化したものをCN（Common Name）[＝EPKc(SUBJECTa＋SNan)]として用い、このCNに前記公開鍵証明書PKCaの発行者名(ISSUERa)を付与したもの[EPKc(SUBJECTa＋SNan)+ISSUERa]が発行者名(ISSUERan)となっている。

このように、本実施形態では発行者名にシリアル番号(SNan)を含ませることで、同一ユーザにより発行される代理証明書であっても発行者名に関連性が無くなるので、ユーザの匿名性を保護できるようになる。

ステップＳ２０３では、前記代理証明書PCanを含むサービス要求がサービス提供サーバ１へ向けて送信される。サービス提供サーバ１は、ユーザ端末２ａから前記代理証明書PCanを含むサービス要求を受信すると、当該代理証明書PCanを含む検証要求メッセージを前記ユーザ管理システム３へ送信して検証を要求する。

図６は、サービス提供サーバ１から転送された代理証明書PCanを受信したユーザ管理システム３による検証手順を示したフローチャートである。

ステップＳ３０１では、受信した代理証明書PCanの発行者に関する管理ドメインがユーザ管理システム３の管理下にあるか否か(すなわち、代理証明書の発行者のCN以外の部分がユーザ管理システム３を表すか否か)が判定される。管理下にあればステップＳ３０２へ進み、前記代理証明書PCanに登録されている発行者のCN（公開鍵PKcで暗号化されている）が、ユーザ管理システム３の秘密鍵SKcにより復号化され、前記公開鍵証明書PKCaの所有者名(SUBJECTa)と代理証明書PCanのシリアル番号(SNan)とが再生される。ステップＳ３０３では、前記再生されたシリアル番号(SNan)と代理証明書PCanに登録されているシリアル番号とが比較され、両者が一致すればステップＳ３０４へ進む。

ステップＳ３０４では、前記再生された所有者名(SUBJECTa)からユーザ識別子IDaが抽出される。ステップＳ３０５では、このユーザ識別子IDaをパラメータとしてディレクトリ４が検索され、当該ユーザ識別子IDaと対応付けられている公開鍵証明書PKCaが取得される。ステップＳ３０６では、この公開鍵証明書PKCaに付与されている署名の検証、検証時点が有効期限内であるかの検証、検証対象証明書が失効されていないかの検証、公開鍵証明書を発行した機関の証明書が失効されていないか等の検証が行われ、これら全てに問題が無いことが確認されれば、ステップＳ３０７において、その公開鍵証明書PKCaが有効(検証OK)と判定される。

これに対して、前記ステップＳ３０６において、署名の検証や検証時点が有効期限内であるかの検証等のいずれかが無効となれば、ステップＳ３０８において、前記公開鍵証明書PKCaが無効(検証NG)と判定される。なお、前記ステップＳ３０１において、発行者の管理ドメインが管理下にないと判定された場合や、あるいはステップＳ３０３において、シリアル番号が不一致と判定された場合も同様に、前記ステップＳ３０８へ進んで公開鍵証明書PKCaが無効と判定される。ステップＳ３０９では、前記検証結果がサービス提供サーバへ返信される。

以上のようにして、代理証明書PCanの有効性が確認されると、サービス提供サーバはユーザAに対して認証を行い、その後、要求されたサービスが提供されるようになる。

図９は、前記ユーザ管理システム３がサービス提供サーバ１から受信した情報要求に応答して、ユーザの属性情報の一部または全部をサービス提供サーバ１へ提供する手順を示したフローチャートであり、図１０は、そのシーケンスフローである。

ステップＳ４０１において、サービス提供サーバ１から送信された属性情報要求を受信すると、ステップＳ４０２では、当該情報要求に含まれるユーザAの代理証明書PCanが抽出される。ステップＳ４０３では、サービス提供サーバ１から当該サービス提供サーバ１の公開鍵証明書PKCbを受信し、この公開鍵証明書PKCbに対応した秘密鍵SKbをサービス提供サーバ１が所持しているか否かを確認することで認証が行われる。

この認証に成功すればステップＳ４０４へ進み、ユーザAにより発行された代理証明書PCanに登録されている公開先リストがユーザ管理システム３の秘密鍵SKcで復号されて取得される。ステップＳ４０５では、当該公開先リストに前記サービス提供サーバ１の所有者名(SUBJECTb)が登録されているか否かが判定される。登録されていればステップＳ４０６へ進み、登録されていなければステップＳ４０９へ進む。ステップＳ４０９では、属性情報要求に応じられない旨のエラーメッセージが前記サービス提供サーバ１へ返信される。

これに対して、前記ステップＳ４０５において、公開先リストにサービス提供サーバ１の所有者名(SUBJECTb)が登録されていると判定されればステップＳ４０６へ進み、代理証明書PCanの所有者名(SUBJECTan)と公開属性情報項目リストとを含む検索要求がディレクトリ４へ通知される。この検索要求に対して、ディレクトリ４から検索結果（属性情報）が返信され、これがステップＳ４０７で受信されるとステップＳ４０８へ進み、当該検索結果が前記サービス提供サーバ１へ返信される。

このように、本発明によればユーザがサービスの提供を受けるために各サービス提供サーバへ登録すべき属性情報が、ユーザ管理システムに登録されて一括管理される。したがって、属性情報の一部を変更する場合でも、ユーザ管理システムに登録されている属性情報のみを変更すれば、この変更が各サービス提供サーバへ公開される属性情報に反映されるようになる。

なお、上記した実施形態では、属性情報の公開が許可されている全てのサービス提供サーバ１へ同一の属性情報が公開される場合を例にして説明したが、本発明はこれのみに限定されるものではなく、各サービス提供サーバ１に重要度や優先度を設定し、サービス提供サーバに応じて属性情報の公開内容が異なるようにしても良い。このようにすれば、公開対象の属性情報を公開先のサービス提供サーバに応じて異ならせることができるので、属性情報に関して自由度の高い公開が可能になる。

本発明に係るユーザ認証方法が適用されるユーザ認証システムの構成を示したブロック図である。ユーザがユーザ管理システムへユーザ登録を要求して暗号鍵ペアおよび公開鍵証明書を取得する手順を示したフローチャートである。ユーザがユーザ管理システムへユーザ登録を要求して暗号鍵ペアおよび公開鍵証明書を取得する手順を示したシーケンスフローである。公開鍵証明書のフォーマットの一例を示した図である。ユーザがサービス提供サーバへアクセスし、認証手順を経てサービスの提供を受けるまでの手順を示したフローチャートである。ユーザがサービス提供サーバへアクセスし、認証手順を経てサービスの提供を受けるまでの手順を示したフローチャートである。ユーザがサービス提供サーバへアクセスし、認証手順を経てサービスの提供を受けるまでの手順を示したシーメンスフローである。代理証明書のフォーマットの一例を示した図である。ユーザ管理システムがサービス提供サーバからの属性情報要求に応答して、ユーザの属性情報を提供する手順を示したフローチャートである。ユーザ管理システムがサービス提供サーバからの属性情報要求に応答して、ユーザの属性情報を提供する手順を示したシーケンスフローである。

符号の説明

１…サービス提供サーバ，２…ユーザ端末，３…ユーザ管理システム，４…ディレクトリ

Claims

ユーザ端末、前記ユーザ端末の要求に応答して公開鍵証明書を発行するユーザ管理システムおよび各ユーザ端末の要求に応答してサービスを提供する複数のサービス提供サーバを含むネットワーク上で、ユーザ管理システムが各ユーザの情報を一元管理するユーザ情報管理方法において、
ユーザ端末がユーザ管理システムへ、ユーザの属性情報を含む登録要求を送信する手順と、
ユーザ管理システムが前記登録要求に応答して、第１ユーザ識別子ならびに第１公開鍵および第１秘密鍵の暗号鍵ペアを生成する手順と、
前記ユーザ管理システムが、前記第１公開鍵に関する公開鍵証明書を生成する手順と、
前記ユーザ管理システムが、前記第１ユーザ識別子、第１公開鍵、第１秘密鍵、公開鍵証明書および属性情報を相互に対応付けて記憶する手順と、
前記ユーザ管理システムがユーザ端末へ、前記第１ユーザ識別子、第１公開鍵、第１秘密鍵および公開鍵証明書を送信する手順と、
前記ユーザ端末が、第２ユーザ識別子ならびに第２公開鍵および第２秘密鍵の暗号鍵ペアを生成する手順と、
前記ユーザ端末が、前記第２公開鍵に関して代理証明書を発行する手順と、
前記ユーザ端末が前記サービス提供サーバへ、前記代理証明書を含むサービス要求を送信する手順と、
前記サービス提供サーバが前記ユーザ管理システムへ、前記代理証明書を含む属性情報要求を送信する手順と、
前記ユーザ管理システムが、前記属性情報要求に応答して前記サービス提供サーバを認証する手順と、
前記ユーザ管理システムが、受信した代理証明書に基づいて属性情報を検索し、検索結果を前記サービス提供サーバへ送信する手順とを含むことを特徴とするユーザ情報管理方法。
前記サービス提供サーバが、前記ユーザ端末から受信した代理証明書を含む検証要求をユーザ管理システムへ送信する手順と、
前記ユーザ管理システムが、受信した代理証明書に対応した公開鍵証明書を抽出する手順と、
前記ユーザ管理システムが、前記抽出した公開鍵証明書および受信した代理証明書を検証する手順と、
前記ユーザ管理システムが、前記検証結果を前記サービス提供サーバへ送信する手順とをさらに含むことを特徴とする請求項１に記載のユーザ情報管理方法。
前記代理証明書が、
公開対象の属性情報を特定する情報と、
公開先のサービス提供サーバを特定する情報とを含み、
公開先として特定されたサービス提供サーバに対してのみ、公開対象として特定された属性情報が公開されることを特徴とする請求項１に記載のユーザ情報管理方法。
前記公開対象の属性情報が公開先のサービス提供サーバに応じて異なることを特徴とする請求項３に記載のユーザ情報管理方法。
ユーザ端末、前記ユーザ端末の要求に応答して公開鍵証明書を発行するユーザ管理システムおよび各ユーザ端末の要求に応答してサービスを提供する複数のサービス提供サーバを含むネットワーク上で、ユーザ管理システムが各ユーザの情報を一元管理するユーザ情報管理システムにおいて、
ユーザ管理システムが、
ユーザの属性情報を含む登録要求に応答して、第１ユーザ識別子ならびに第１公開鍵および第１秘密鍵の暗号鍵ペアを生成する手段と、
前記第１公開鍵に関する公開鍵証明書を生成する手段と、
前記第１ユーザ識別子、第１公開鍵、第１秘密鍵、公開鍵証明書および属性情報を相互に対応付けて記憶する手段と、
前記ユーザ端末へ、前記第１ユーザ識別子、第１公開鍵、第１秘密鍵および公開鍵証明書を送信する手段とを含み、
前記ユーザ端末が、
ユーザの属性情報を含む登録要求をユーザ管理システムへ送信する手段と、
第２ユーザ識別子ならびに第２公開鍵および第２秘密鍵の暗号鍵ペアを生成する手段と、
前記第２公開鍵に関して代理証明書を発行する手段と、
前記代理証明書を含むサービス要求を前記サービス提供サーバへ送信する手段とを含み、
前記サービス提供サーバが
前記代理証明書を含む属性情報要求を前記ユーザ管理システムへ送信する手段を含み、
前記ユーザ管理システムがさらに、
前記属性情報要求に応答して前記サービス提供サーバを認証する手段と、
受信した代理証明書に基づいて属性情報を検索し、検索結果を前記サービス提供サーバへ送信する手段とを含むことを特徴とするユーザ情報管理システム。