JPH118619A - 電子証明書発行方法及びシステム - Google Patents

Abstract

(57)【要約】 【課題】 低コストで証明書を発行することとその発行
の際のセキュリティ強度を高めること。 【解決手段】 証明書を発行してもらう被認証者に対し
て認証局がネットワークを介して電子証明書を発行する
電子証明書発行方法であって、ある認証局が既に発行し
た公開鍵の電子証明書とその電子証明書における被認証
者の公開鍵に対して、前記電子証明書で証明済の鍵でデ
ジタル署名を施したものと発行を要求する証明書名の入
力を受け、前記被認証者のデジタル署名が妥当であるか
否かを検証し、妥当であると検証できたときは、前記電
子証明書で発行可能な証明書のリストと照合し、前記被
認証者が要求した証明書が発行可能である場合には、送
信された電子証明書の検証を行い、検証できた場合に、
前記被認証者の公開鍵を認証した電子証明書を発行す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、公開鍵暗号方式を
用いたオープンなネットワーク上で行われる電子証明書
発行およびシステムに関し、特に低コストで証明書を発
行できる電子証明書発行方法およびシステムに適用して
有効な技術に関するものである。

【０００２】

【従来の技術】近年では、インターネットなどオープン
なネットワーク上で電子商取引が行われているが、イン
ターネットを用いて電子商取引を行う場合には個人情報
等のデータのやり取りの安全性が問題となっている。

【０００３】つまり、データの漏洩や、改竄、配送元の
なりすまし等の犯罪を比較的容易に行うことができるか
らである。

【０００４】このような問題に対して、従来では、共通
鍵暗号方式や、公開鍵暗号方式といった暗号化方式を使
って、安全なデータのやり取りが実現されている。

【０００５】ここで、共通鍵暗号方式とは、暗号化する
時に使用する鍵と復号化する時に使用する鍵が同じであ
る暗号方式であり、暗・復号速度が高速なので、大量の
データを暗号化するのに適している。

【０００６】これに対して公開鍵暗号方式とは、他者に
見せない鍵（秘密鍵）と、それに対応する、他者に公開
する鍵（公開鍵）とのペアからなり、一方の鍵を使用し
て作られた暗号文は、ペアのもう一方の鍵を使用しなけ
れば復号化できない方式であり、また、一方の鍵からも
う片方の鍵を類推することは困難であるという性質をも
っており、不特定多数の人と通信することに適してい
る。

【０００７】また、これらの他にも認証局という、信頼
できる第３者機関が発行した電子証明書（以下、証明書
と記す）を使用することにより、通信相手の身元を証明
し、通信元のなりすましを防止する方法が提案されてい
る。

【０００８】この認証局が証明書を発行する手順は、次
の通りである。

【０００９】まず、被認証者が認証局に対して発行要求
メッセージを送り、認証局から認証局の証明書を入手す
る。認証局の証明書を受理した被認証者は、証明書を検
証する。その証明書が、上位認証局により発行されてい
た場合、その上位認証局の証明書を入手することを繰り
返す。最終的に信用できる最上位の認証局の証明書を検
証することにより判断する。検証できたときは、認証局
に対して、発行の申請を行う証明書の種類がわかるよう
な情報および登録フォーム要求メッセージを送る。ここ
で、登録フォームとは、証明書発行に必要な事柄を記入
するフォームである。

【００１０】このメッセージを受理した認証局は、証明
書の種類を確定しその証明書発行に必要な項目を記入す
る登録フォームにデジタル署名をつけて被認証者に送
る。

【００１１】ここで、デジタル署名とは、具体的には、
署名したいメッセージをハッシュ関数とよばれる特殊な
関数を用いて、一定の長さのハッシュ値とよばれる値に
変換したものを作成し、そのハッシュ値に対してメッセ
ージ作成者の秘密鍵で暗号化することである。ハッシュ
値は一意に定まるため、受け取ったメッセージのハッシ
ュと、受け取ったデジタル署名を公開鍵で復号化したも
のが一致するかどうかを確認することにより、メッセー
ジの改竄を確認することができる。

【００１２】デジタル署名つき登録フォームを受け取っ
た被認証者は、署名を確認し、確認できたとき、被認証
者の登録鍵、すなわち公開鍵と秘密鍵を生成し、公開鍵
と登録者本人であることの根拠となる個人情報、たとえ
ば口座番号とを暗号化して認証局に送る。

【００１３】認証局は、送られてきたメッセージを復号
化して、登録者本人であることの根拠となる個人情報
を、その情報に関する機関に問い合わせることによって
確認する。例えば、個人情報として口座番号を用いた場
合は、銀行に問い合わせることになる。問い合わせた結
果、情報が正しいならば、被認証者の公開鍵の証明書を
作成し、この証明書を被認証者へ送る。

【００１４】以上のような手順は、例えば、SET(Secure
Electronic Transaction Specification ,Draft for t
esting, June 17,1996, MasterCard, VISA)で用いられ
ている。

【００１５】

【発明が解決しようとする課題】本発明者は、上記従来
技術を検討した結果、以下の問題点を見いだした。

【００１６】証明書発行の際に登録者本人であることを
確認する従来の方法は、被認証者から認証局へ口座番号
を送り、認証局がその口座番号が正しいかどうかを銀行
に確認することによって行われている。

【００１７】この方法では、証明書発行の際に口座番号
の確認を認証局とは別の機関（銀行）に依頼しているた
め、コストが大きくなるという問題点がある。

【００１８】また、暗号化されているとはいえ、証明書
とは直接関係のない個人情報が、オープンなネットワー
ク上を通過するという問題点もある。

【００１９】本発明の目的は、被認証者が既に取得して
いる証明書を本人認証の根拠とすることにより、本人認
証のコストを下げ、証明書発行にかかるコストを下げる
ことが可能な技術を提供することにある。

【００２０】本発明の他の目的は、証明書発行依頼の際
に、既に発行されている証明書を基に個人情報（例え
ば、口座番号）というプライバシーおよびセキュリティ
上に問題のある情報を送信せずに済ませることにより、
全体のセキュリティ強度を高めることが可能な技術を提
供することにある。

【００２１】本発明の前記ならびにその他の目的と新規
な特徴は、本明細書の記述及び添付図面によって明らか
になるであろう。

【００２２】

【課題を解決するための手段】本願において開示される
発明のうち、代表的なものの概要を簡単に説明すれば、
下記のとおりである。

【００２３】証明書を発行してもらう被認証者に対して
認証局がネットワークを介して電子証明書を発行する電
子証明書発行方法であって、ある認証局が既に発行した
公開鍵の電子証明書とその電子証明書における被認証者
の公開鍵に対して、前記電子証明書で証明済の鍵でデジ
タル署名を施したものと発行を要求する証明書名の入力
を受け、前記被認証者のデジタル署名が妥当であるか否
かを検証し、妥当であると検証できたときは、前記電子
証明書で発行可能な証明書のリストと照合し、前記被認
証者が要求した証明書が発行可能である場合には、送信
された電子証明書の検証を行い、検証できた場合に、前
記被認証者の公開鍵を認証した電子証明書を発行する。

【００２４】また、電子証明書を発行してもらう被認証
者のクライアントと、前記被認証者に電子証明書を発行
する認証局のサーバとがネットワークを介して接続され
てなる電子証明書発行システムであって、前記被認証者
のクライアントは、ある認証局が既に発行した公開鍵の
電子証明書とその電子証明書における被認証者の公開鍵
に対し、前記電子証明書で証明済の鍵でデジタル署名
し、前記認証局のサーバに送信して他の電子証明書の発
行要求を行う発行要求手段と、前記認証局から送信され
てきた電子証明書を保存する手段とを備え、前記認証局
のサーバは、各電子証明書から発行可能な他の電子証明
書群をまとめた発行可能証明書リストと、前記被認証者
のデジタル署名が妥当であるか否かを検証する署名検証
手段と、前記署名検証手段により、署名が妥当であると
検証できたときに、送信されてきた送信電子証明書と発
行可能証明書リストと照合する証明書照合手段と、前記
証明書照合手段により、前記被認証者が要求した要求電
子証明書が発行可能であるとき、前記被認証者からの送
信電子証明書の検証を行う電子証明書検証手段と、前記
電子証明書検証手段により、前記送信電子証明書が検証
されたとき、前記被認証者の公開鍵を認証した要求電子
証明書を発行する手段とを備える。

【００２５】

【発明の実施の形態】以下、本発明の実施の形態を図面
を用いて説明する。

【００２６】図１は、本発明の一実施形態にかかる証明
書発行システムの構成を示すブロック図である。本実施
形態では、既に取得してあるクレジットカードを基に新
たな電子証明書を取得する場合を例に取り挙げて説明し
ていく。

【００２７】本実施形態の証明書発行システムは、図１
に示すように、電子証明書（以下、証明書と略す）を発
行する認証局１０と、証明書発行を依頼する被認証者
（以下、カード所有者と記す）のクライアント２０と、
電子商取引を行うネットワークであるインターネット３
０とから構成される。

【００２８】上述した認証局１０は、実際の処理を行う
認証局サーバ１１０と、カード所有者のクライアント２
０からインタネット３０経由で入力を受け付け、認証局
サーバ１１０へ中継し、その結果を認証局サーバ１１０
からカード所有者のクライアント２０へ送信する認証局
Ｗｅｂサーバ１２０とから構成される。

【００２９】認証局サーバ１１０は、認証局Ｗｅｂサー
バ１２０と通信を行う通信装置１１２と、表示器１１３
と、キーボード１１４と、証明書データベース、証明書
名データベース、認証局の署名鍵および交換鍵が格納さ
れる記憶装置１１５と、これら全てを制御する制御装置
１１１とからなる。

【００３０】認証局Ｗｅｂサーバ１２０は、認証局サー
バ１１０と通信を行う通信装置１２２と、インターネッ
トに接続される通信装置１２３と、表示器１２４と、キ
ーボード１２５と、Ｗｅｂサーバソフトウエアが格納さ
れる記憶装置１２６と、これら全てを制御する制御装置
１２１とからなる。

【００３１】カード所有者のクライアント２０では、証
明書データベースやカードホルダの署名鍵、共通鍵など
を格納する記憶装置２１１と、インターネットに接続す
る通信装置２１２と、表示器２１３と、キーボード２１
４と、これら全てを制御する制御装置２１０とからな
る。

【００３２】図２は、認証局１０の構成を詳細に説明す
るための図である。

【００３３】図２に示すように、認証局１０の認証局サ
ーバ１１０の記憶装置１１５には、証明書データベース
１１５４０と証明書名データベース１１５３０、署名鍵
公開鍵PBCPSG（１１５１１）と署名鍵個人鍵PVCPSG（１
１５１２）とその証明書１１５１３とからなる認証局の
署名鍵１１５１０、鍵交換鍵公開鍵PBCPEX（１１５２
１）と鍵交換鍵個人鍵PVCPEX（１１５２２）とその証明
書１１５２３とからなる鍵交換鍵１１５２０が保存され
ている。

【００３４】この証明書データベース１１５４０は、公
開鍵１１５４３と、その公開鍵の対象（持ち主）１１５
４２、証明書１１５４１をレコードとするデータベース
であり、証明書名データベース１１５３０は、証明書名
１１５３２と、その証明書を発行するのに必要となる条
件である証明書名組１１５３３と、その証明書を使用す
るブランド１１５３１をレコードとするデータベースで
ある。

【００３５】制御装置１１１は、通信装置１１２を通じ
て認証局Ｗｅｂサーバ１２０に接続され、必要に応じて
証明書データベース１１５４０に格納されている証明書
１１５４１、および証明書名データベース１１５３０に
格納されている証明書名組１１５３３、認証局１０の署
名鍵公開鍵１１５１１および署名鍵個人鍵１１５１２を
認証局Ｗｅｂサーバ１２０へ送信する。

【００３６】認証局Ｗｅｂサーバ１２０の制御装置１２
１は、認証局Ｗｅｂサーバ１２０のＷｅｂサーバソフト
ウエア１２６１０を記憶装置１２６からロードし、実行
する。

【００３７】Ｗｅｂサーバソフトウエア１２６１０は、
http（Hypertext Transport Protocol）に基づいて通信
を行うプログラムである。

【００３８】図３は、カード所有者のクライアント２０
を詳細に説明するための図である。

【００３９】カード所有者２０のクライアントの記憶装
置２１１には、Ｗｅｂブラウザソフトウエア２１１１０
と、署名鍵秘密鍵２１１６０と、証明書データベース２
１１４０と、カード所有者２０の署名鍵公開鍵PBCHSG’
（２１１２０）および署名鍵個人鍵PVCHSG’（２１１３
０）と、それぞれの共通鍵＃１〜＃３（２１１７１〜２
１１７３）と、署名鍵公開鍵リスト２１１８０とが保存
される。

【００４０】証明書データベース２１１５０は、署名鍵
公開鍵名２１１５３、その証明書が使える相手（ブラン
ド名）２１１５２、証明書２１１５１をレコードとする
データベースである。

【００４１】次に、図４を用いて本実施形態の証明書発
行システムの各制御装置における証明書発行処理の概要
の説明を行い、その後、各ステップの詳細をそれぞれの
図を用いて説明する。

【００４２】カード所有者が、Ｗｅｂブラウザソフトウ
エア２１１１０を通じて、認証局１０に対して、証明書
発行を依頼する（ステップ４０１）。

【００４３】認証局１０は、カード所有者のクライアン
ト２０から証明書発行依頼を受け取ると、証明書発行要
求応答を生成してカード所有者のクライアント２０に送
信する。このとき、カード所有者へ認証局の公開鍵を送
付する（ステップ４０２）。

【００４４】カード所有者は、認証局１０から証明書発
行要求応答を受け取り、認証局１０の証明書の検証を行
い、登録フォーム要求を認証局１０へ送信する（ステッ
プ４０３）。

【００４５】認証局１０は、カード所有者のクライアン
ト２０から登録フォーム要求を受け取ると、登録フォー
ムを生成し、カード所有者のクライアント２０に送信す
る（ステップ４０４）。

【００４６】カード所有者は、登録フォームに必要事項
を記入し、証明書要求を認証局１０へ送付する。このと
き、カード所有者は、カード所有者の公開鍵を送付する
(ステップ４０５）。

【００４７】認証局１０は、カード所有者のクライアン
ト２０から送られてきた登録フォームに含まれている証
明書を検証する（ステップ４０６）。

【００４８】認証局１０は、ステップ４０６の検証結果
に応じて、証明書を発行し、カード所有者のクライアン
ト２０に送付する（ステップ４０７)。

【００４９】カード所有者のクライアント２０では、発
行された証明書を検証し、保存する（ステップ４０
８）。

【００５０】上述したステップ４０２の詳細を図５を用
いて説明する。

【００５１】ステップ４０２は、まず、認証局サーバ１
１０が、証明書発行申請メッセージに対する応答メッセ
ージを生成し、署名する（ステップ５０１）。

【００５２】認証局１０は、認証局１０の鍵交換鍵及び
署名鍵のそれぞれの公開鍵PBCPEX（１１５２１）、PBCP
SG（１１５１１）と、それぞれの証明書CertPBCPEX（１
１５２３）、CertPBCPSG（１１５１３）と、ステップ５
０１で作成した署名つき応答メッセージを、カード所有
者のクライアント２０に送信する(ステップ５０２)。

【００５３】次に、上述したステップ４０３を図６を用
いて詳細に説明する。

【００５４】ステップ４０３は、まず、カード所有者の
クライアント２０が、証明書CertPBCPEX（１１５２
３）、CertPBCPSG（１１５１３）の妥当性を、SET(Secu
re Electronic Transaction Specification, Draftfor
testing, June 17, 1996, MasterCard, VISA, BookII,
PartII Certificate Management, Ch.1, Sec.3, Certif
icate Chain Validation) と同様に検証する（ステップ
６０１）。この妥当性の検証は、例えば、証明書が有効
期限内であるか否かのチェック等である。

【００５５】検証の結果、妥当でなければ処理を中断
し、妥当であれば処理を続ける（ステップ６０２）。

【００５６】カード所有者は、キーボード２１４を通じ
て登録フォーム選択情報を取り込む（ステップ６０
３）。ここで、登録フォーム選択情報とは、消費者が発
行してもらいたい証明書を選択するために必要な情報で
ある。例えば、その証明書が利用できるカード会社名
（ブランド名）などである。

【００５７】カード所有者のクライアント２０は、登録
フォーム要求メッセージおよび共通鍵（＃１）SymK＃１
を作成する（ステップ６０４）。

【００５８】カード所有者のクライアント２０は、登録
フォーム要求メッセージを共通鍵SymK ＃１で暗号化
し、また、登録フォーム選択情報と共通鍵SymK ＃１を
認証局の鍵交換鍵公開鍵PBCPEX（１１５２１）で暗号化
する（ステップ６０５）。

【００５９】カード所有者２０は、ステップ６０５で作
成したメッセージを認証局１０へ送信する（ステップ６
０６）。

【００６０】次に、上述したステップ４０４を図７を用
いて詳細に説明する。

【００６１】ステップ４０４は、まず、認証局１０が、
認証局１０の鍵交換鍵個人鍵PVCPEX１（１５２２）で、
登録フォーム選択情報と共通鍵SymK ＃１を復号化し
（ステップ７０１）、続いて、共通鍵SymK＃１で登録フ
ォーム要求を復号化し（ステップ７０２）、登録フォー
ム選択情報から証明書発行に必要な証明書名組を決定
し、登録フォームを作成する（ステップ７０３）。この
証明書名組の決定の方法としては、例えば、 （１）登録フォーム選択情報に記述されているブランド
名をキーにして、認証局の証明書名データベースから検
索する （２）登録フォーム選択情報にブランド名だけでなく、
必要な証明書名組まで含めておく などがある。

【００６２】そして、認証局１０は、ステップ７０３で
作成した登録フォームに対して、認証局１０の署名鍵個
人鍵PVCPSG（１１５１２）で署名し（ステップ７０
４）、ステップ７０４で作成した署名つき登録フォーム
に、認証局１０の証明書CertPBCPSG（１１５１３）をつ
け、カード所有者のクライアント２０へ送信する（ステ
ップ７０５）。このように、前記証明書名データベース
を基に、送信電子証明書で発行可能な他の証明書のリス
ト、または証明書の発行に必要となる証明書組をカード
所有者のクライアントに送信することにより、証明書発
行にかかる手間を少なくすることができる。

【００６３】次に、上述したステップ４０５を図８を用
いて詳細に説明する。

【００６４】ステップ４０５は、図８に示すように、ま
ず、カード所有者のクライアント２０が、受信した署名
の証明書CertPBCPSGの妥当性を、SETと同様な手段によ
り検証する（ステップ８０１）。

【００６５】その検証の結果、妥当でなければ処理を中
断し、妥当であれば処理を続け（ステップ８０２）、カ
ード所有者の署名鍵公開鍵PBCHSG'（２１１２０）およ
び秘密鍵PVCHSG'（２１１６０）を生成し、記憶装置２
１１に保存し（ステップ８０３）、受信した登録フォー
ムに必要事項を記入してこれを登録事項とする（ステッ
プ８０４）。

【００６６】その後、カード所有者のクライアント２０
は、受信した証明書名組にしたがって、証明書データベ
ース２１１４０から証明書を検索し、証明書組を作成す
る（ステップ８０５）。

【００６７】ここで、証明書組とは、１個以上の複数個
の証明書を、例えばリスト構造のように、ひとつのまと
まりにしたものである。

【００６８】カード所有者は、その証明書組を構成して
いる複数個の証明書からカード所有者の署名鍵公開鍵２
１１２０を取り出し、カード所有者署名鍵公開鍵リスト
PBCHSGL（２１１８０）とする（ステップ８０６）。

【００６９】その後、カード所有者のクライアント２０
は、共通鍵SymK ＃２（２１１７２）、共通鍵SymK ＃３
（２１１７３）を生成して記憶装置２１１に保存し（ス
テップ８０７）、登録事項を含んだ証明書要求メッセー
ジを作成する（ステップ８０８）。

【００７０】カード所有者２０は、証明書要求メッセー
ジおよびカード所有者の署名鍵公開鍵PBCHSG'（２１１
２０）、共通鍵SymK ＃２（２１１７２）に対して、カ
ード所有者の署名鍵公開鍵PBCHSG"" で署名をつける
（ステップ８０９）。ここで、PBCHSG"" はカード所有
者署名鍵公開鍵リストPBCHSGL（２１１８０）に含まれ
ているいずれか１個の公開鍵である。このPBCHSG""の選
び方は、例えば、PBCHSGLの先頭の公開鍵を選択すると
よい。このステップ８０９で、PBCHSG""の代わりにPBCH
SGを使用すると、不正な証明書を使用することができる
ため、PBCHSG"" を使用することが必須である。なお、
既存のSETでは、本人確認を口座番号などを利用して行
っているためPBCHSGを使用しても構わない。登録する公
開鍵PBCHSG' は、PBCHSG"" と同一とすることもでき
る。

【００７１】カード所有者のクライアント２０は、ステ
ップ８０９の結果を、共通鍵SymK＃３（２１１７３）で
暗号化し（ステップ８１０）、続いて、証明書組と共通
鍵SymK ＃３（２１１７３）を、認証局の鍵交換鍵公開
鍵PBCPEX（１１５２１）で暗号化し（ステップ８１
１）、ステップ８１０およびステップ８１１で作成した
ものを、認証局１０へ送信する（ステップ８１２）。

【００７２】次に、上述したステップ４０６を図９を用
いて詳細に説明する。

【００７３】ステップ４０６は、図９に示すように、ま
ず、認証局１０が、カード所有者のクライアント２０か
ら受信したメッセージに対して、認証局の鍵交換鍵個人
鍵PVCPEX（１１５２２）を使って、証明書組と共通鍵Sy
mK ＃３（２１１７３）を復号化する（ステップ９０
１）。

【００７４】その後、認証局１０は、図８に示したステ
ップ８１０で暗号化された部分を共通鍵SymK ＃３（２
１１７３）で復号化し（ステップ９０２）、カード所有
者の署名をカード所有者の署名鍵公開鍵PBCHSG""を使っ
て検証し（ステップ９０３）、検証の結果、妥当でなけ
れば処理を中断し、妥当であれば処理を続行する（ステ
ップ９０４）。

【００７５】次に、上述したステップ４０８を図１０を
用いて詳細に説明する。

【００７６】ステップ４０７は、図１０に示すように、
まず、認証局１０が、証明書組を分解し（ステップ１０
０１）、各々の証明書を検証し、証明書値を計算する
（ステップ１００２）。

【００７７】その後、認証局１０は、証明書要求メッセ
ージから発行する証明書の名前を取り出し、証明書名デ
ータベース１１５３０からその証明書を発行するために
必要な証明書名組１１５３３を検索し（ステップ１００
３）、ステップ１００１の証明書名組１１５３３にステ
ップ１００２の証明書値を代入して、証明書組値を計算
する（ステップ１００４）。ここでの証明書値は、証明
書が妥当であれば”t”、妥当でなければ”f”と言う値
を取る。また、証明書名組とは、複数の証明書名CN
1,...CNnを論理演算子(∧、∨、¬)で結合したものであ
る。

【００７８】例えば、(C1∧C2)∨(¬C3) は、証明書名
組であり、その証明書名組の値とは、それぞれの証明書
の値を証明書名組の「証明書名」へ代入し、論理演算し
た結果の値である。計算（論理演算）には、以下の論理
規則を用いる。

【００７９】A, B, C は、0 個以上のt,fを∧,∨,¬で
結合した式を表す。結合度は、¬, ∧, ∨の順で弱くな
る。

【００８０】(1) t ∧t →t (2) t ∧f →f (3) f ∧t →f (4) f ∧f →f (5) t ∨t →t (6) t ∨f →t (7) f ∨t →t (8) f ∨f →f (9) ¬t →f (10) ¬f →t (11) A ∧B ∧C →(A ∧B) ∧C (12) A ∨B ∨C →(A ∨B) ∨C その後、認証局１０は、その他の条件を確認する。ここ
で、「その他の条件」とは、証明書の妥当性以外の条件
であり、例えば、「ある友の会の会員である」、「年齢
が35歳以上である」などのカード所有者本人を確認する
ものである。これらの条件を、認証局１０は、オンライ
ンあるいはオフラインで確認し、その結果、条件に合っ
ていれば条件値を”t” とし、条件に合わなければ条件
値を”f” とする（ステップ１００５）。これにより、
より確実に証明書の検証を行うことが可能になる。

【００８１】その後、認証局１０は、ステップ１００
４、ステップ１００５の結果、証明書組値∧条件値を前
述の論理規則にしたがって計算し、その結果が”f”で
あれば処理を中断し、その結果が”t”であれば処理を
続行する（ステップ１００６）。

【００８２】そして、証明書組値が”t”の場合、認証
局１０は、カード所有者に対して、請求されていた証明
書を発行するため、カード所有者の署名鍵公開鍵PBCHS
G'（２１１２０）に対して認証局１０が署名した証明書
CertPBCHSG'（２１１４０）を作成し（ステップ１００
７）、証明書要求応答メッセージを作成、署名して、共
通鍵SymK ＃２（２１１７２）で暗号化し（ステップ１
００８）、証明書CertPBCHSG'（２１１４０）、およ
び、ステップ１００８で作成した署名つき証明書要求応
答メッセージを暗号化したものと、認証局１０の証明書
CertPBCPSG（１１５１３）とを、カード所有者２０に対
して送信する（ステップ１００９）。

【００８３】次に、上述したステップ４０９を図１１を
用いて詳細に説明する。

【００８４】ステップ４０９は、図１１に示すように、
まず、カード所有者のクライアント２０が、認証局から
受信した証明書CertPBCPSG（２１１１３）の妥当性を、
上述したように、SETと同様に検証する（ステップ１１
０１）。

【００８５】その検証の結果、妥当でなければ処理を中
断し、妥当であれば処理を続け（ステップ１１０２）、
共通鍵Sym ＃２（２１１７２）を記憶装置２１１から取
り出し、この共通鍵Sym ＃２（２１１７２）で証明書応
答メッセージを復号化し（ステップ１１０３）、認証局
１０の署名鍵公開鍵PBCPSG（１１５１１）で署名を検証
し（ステップ１１０４）、署名が確認されなければ処理
を中断し、確認されれば処理を続行する（ステップ１１
０５）。

【００８６】そして、カード所有者のクライアント２０
は、発行された証明書CertPBCHSG'（２１１４０）を記
憶装置２１１に保存する（ステップ１１０６）。

【００８７】したがって、説明してきたように、ある認
証局が既に発行した公開鍵の証明書とその証明書におけ
るカード所有者の公開鍵に対して、証明書で証明済の鍵
でデジタル署名を施したものと発行を要求する証明書名
の入力を受け、カード所有者のデジタル署名が妥当であ
るか否かを検証し、妥当であると検証できたときは、証
明書と証明書名データベースとを照合し、カード所有者
が要求した証明書が発行可能である場合には、送信され
た証明書の検証を行い、検証できた場合に、カード所有
者の公開鍵を認証した証明書を発行することにより、カ
ード所有者の身元確認の根拠として、電子的に送付可能
で信頼性のある既に取得した証明書を用いることが可能
になり、カード所有者から認証局へ口座番号を送った
り、認証局がその口座番号が正しいかどうかを銀行に確
認したりする必要がなくなるので、低コストで証明書を
発行することが可能になる。

【００８８】また、プライバシーに関わる個人情報を送
付する必要がなくなるため、全体のセキュリティ強度を
高めることが可能になる。

【００８９】なお、上述した証明書発行処理を行う証明
書発行システムの各制御装置は、コンピュータで実行可
能なプログラムで実現される場合もあり、そのときのプ
ログラムは、フロッピーディスク、ＣＤ・ＲＯＭ、マス
クＲＯＭ等の記憶媒体で一般ユーザに提供される。この
場合、さらに、これら処理の他にＧＵＩプログラム等の
他のプログラムと組み合わせてユーザに提供することも
ある。

【００９０】また、上述した記憶媒体で提供する代替手
段として、インタネット等のネットワークを通じて有償
で提供することもある。

【００９１】以上、本発明者によってなされた発明を、
前記実施形態に基づき具体的に説明したが、本発明は、
前記実施形態に限定されるものではなく、その要旨を逸
脱しない範囲において種々変更可能であることは勿論で
ある。

【００９２】

【発明の効果】本願において開示される発明のうち代表
的なものによって得られる効果を簡単に説明すれば、下
記のとおりである。

【００９３】カード所有者の身元確認の根拠として、電
子的に送付可能で信頼性のある既取得証明書を用いるこ
とが可能になり、カード所有者から認証局へ口座番号を
送ったり、認証局がその口座番号が正しいかどうかを銀
行に確認したりする必要がなくなるので、低コストで証
明書を発行することが可能になる。

【００９４】また、プライバシーに関わる個人情報を送
付する必要がなくなるため、全体のセキュリティ強度を
高めることが可能になる。

【図面の簡単な説明】

【図１】本発明の実施形態にかかる電子証明書発行シス
テムの構成を説明するためのブロック図である。

【図２】認証局の構成を詳細に説明するための図であ
る。

【図３】カード所有者のクライアントを詳細に説明する
ための図である。

【図４】本実施形態の証明書発行システムの各制御装置
における証明書発行処理の概要を説明するためのフロー
チャートである。

【図５】認証局が、カード所有者からの証明書要求メッ
セージに応答するメッセージを作成し、カード所有者へ
送信する処理を示すフローチャートである。

【図６】カード所有者が、認証局から証明書要求応答メ
ッセージを受け取って、認証局へ登録フォーム要求メッ
セージを送信する処理を示すフローチャートである。

【図７】認証局が登録フォームを生成し、カード所有者
に送信する処理を示すフローチャートである。

【図８】カード所有者が登録フォームを記入し、証明書
要求を認証局へ送信する処理を示すフローチャートであ
る。

【図９】認証局がカード所有者の証明書組を検証する処
理を示すフローチャートである。

【図１０】認証局が、検証の結果に応じて証明書を発行
し、カード所有者へ証明書を送信する処理を示すフロー
チャートである。

【図１１】カード所有者が、認証局によって発行された
証明書を検証し保存する処理を示すフローチャートであ
る。

【符号の説明】

１０…認証局、２０…クライアント、３０…インターネ
ット、１１０…認証局サーバ、１１１…制御装置、１１
２…通信装置、１１３…表示器、１１４…キーボード、
１１５…記憶装置、１２０…認証局Ｗｅｂサーバ、１２
１…制御装置、１２２…通信装置、１２３…通信装置、
１２４…表示器、１２５…キーボード、１２６…記憶装
置、２１０…制御装置、２１１…記憶装置、２１２…通
信装置、２１３…表示器、２１４…キーボード。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 川連 嘉晃 神奈川県横浜市都筑区加賀原二丁目２番 株式会社日立製作所ビジネスシステム開発 センタ内 (72)発明者 松永 和男 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内 (72)発明者 州崎 誠一 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内

Claims (5)

【特許請求の範囲】
1. 【請求項１】 証明書を発行してもらう被認証者に対し
   て認証局がネットワークを介して電子証明書を発行する
   電子証明書発行方法であって、 ある認証局が既に発行した公開鍵の電子証明書とその電
   子証明書における被認証者の公開鍵に対して、前記電子
   証明書で証明済の鍵でデジタル署名を施したものと発行
   を要求する証明書名の入力を受け、前記被認証者のデジ
   タル署名が妥当であるか否かを検証し、妥当であると検
   証できたときは、前記電子証明書で発行可能な証明書の
   リストと照合し、前記被認証者が要求した証明書が発行
   可能である場合には、送信された電子証明書の検証を行
   い、検証できた場合に、前記被認証者の公開鍵を認証し
   た電子証明書を発行することを特徴とする証明書発行方
   法。
2. 【請求項２】 前記請求項１に記載の電子証明書発行方
   法であって、 前記ある認証局が既に発行した公開鍵の電子証明書とそ
   の電子証明書における被認証者の公開鍵と発行を要求す
   る証明書名と共に予め認証局に登録してある被認証者を
   特定する確認情報を前記電子証明書で証明済の鍵でデジ
   タル署名を施したものの入力を受け、前記被認証者のデ
   ジタル署名が妥当であるか否かを検証し、妥当であると
   検証できた後に、前記被認証者の確認情報の検証を行
   い、検証できたときに前記電子証明書で発行可能な証明
   書のリストと照合することを特徴とする証明書発行方
   法。
3. 【請求項３】 電子証明書を発行してもらう被認証者の
   クライアントと、前記被認証者に電子証明書を発行する
   認証局のサーバとがネットワークを介して接続されてな
   る電子証明書発行システムであって、 前記被認証者のクライアントは、ある認証局が既に発行
   した公開鍵の電子証明書とその電子証明書における被認
   証者の公開鍵に対し、前記電子証明書で証明済の鍵でデ
   ジタル署名し、前記認証局のサーバに送信して他の電子
   証明書の発行要求を行う発行要求手段と、前記認証局か
   ら送信されてきた電子証明書を保存する手段とを備え、 前記認証局のサーバは、各電子証明書から発行可能な他
   の電子証明書群をまとめた発行可能証明書リストと、前
   記被認証者のデジタル署名が妥当であるか否かを検証す
   る署名検証手段と、前記署名検証手段により、署名が妥
   当であると検証できたときに、送信されてきた送信電子
   証明書と発行可能証明書リストと照合する証明書照合手
   段と、前記証明書照合手段により、前記被認証者が要求
   した要求電子証明書が発行可能であるとき、前記被認証
   者からの送信電子証明書の検証を行う電子証明書検証手
   段と、前記電子証明書検証手段により、前記送信電子証
   明書が検証されたとき、前記被認証者の公開鍵を認証し
   た要求電子証明書を発行する手段とを備えたことを特徴
   とする電子証明書発行システム。
4. 【請求項４】 前記請求項３に記載の電子証明書発行シ
   ステムにおいて、 前記被認証者のクライアントの発行要求手段は、予め認
   証局に登録してある被認証者を特定する確認情報を前記
   電子証明書で証明済の鍵でデジタル署名したものを送信
   する手段を備え、 前記認証局のサーバは、前記被認証者の確認情報の検証
   を行う確認情報検証手段を備えたことを特徴とする電子
   証明書発行システム。
5. 【請求項５】 前記請求項３、または４に記載の電子証
   明書発行システムにおいて、 前記認証局のサーバは、前記発行可能証明書リストを基
   に、送信電子証明書で発行可能な他の電子証明書のリス
   ト、または前記要求電子証明書の発行に必要となる電子
   証明書を前記被認証者のクライアントに送信する手段を
   備えたことを特徴とする電子証明書発行システム。