JP2007060539A - 証明書検証システム - Google Patents
証明書検証システム Download PDFInfo
- Publication number
- JP2007060539A JP2007060539A JP2005246219A JP2005246219A JP2007060539A JP 2007060539 A JP2007060539 A JP 2007060539A JP 2005246219 A JP2005246219 A JP 2005246219A JP 2005246219 A JP2005246219 A JP 2005246219A JP 2007060539 A JP2007060539 A JP 2007060539A
- Authority
- JP
- Japan
- Prior art keywords
- certificate
- service device
- service
- verification
- information
- 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.)
- Pending
Links
Images
Abstract
【課題】 証明書検証処理の遅延を少なくする。また、この証明書検証処理の対象を人間にとって直感的に分かりやすくなるように改善する。
【解決手段】 携帯端末4を保持するユーザ6がサービス機器3を利用しようとするとき、携帯端末4はサービス機器3から証明書を取得し、この証明書の信頼情報が予め信頼情報DB5に登録されているか否かを調べ、信頼情報が信頼情報DB5に登録されていないとき、信頼情報を従来と同じ方法で検証処理を実行して信頼できると判断した場合にこの旨を信頼情報として上記信頼情報DB5に登録しておく。また、携帯端末4はサービス機器3の信頼性を調べようとするとき、サービス機器3から取得した証明書の検証処理を実行する代りに、証明書の信頼情報が信頼情報DB5に登録されている場合に、サービス機器3が信頼できると判断してサービス機器3からサービスの提供を受ける。
【選択図】 図1
【解決手段】 携帯端末4を保持するユーザ6がサービス機器3を利用しようとするとき、携帯端末4はサービス機器3から証明書を取得し、この証明書の信頼情報が予め信頼情報DB5に登録されているか否かを調べ、信頼情報が信頼情報DB5に登録されていないとき、信頼情報を従来と同じ方法で検証処理を実行して信頼できると判断した場合にこの旨を信頼情報として上記信頼情報DB5に登録しておく。また、携帯端末4はサービス機器3の信頼性を調べようとするとき、サービス機器3から取得した証明書の検証処理を実行する代りに、証明書の信頼情報が信頼情報DB5に登録されている場合に、サービス機器3が信頼できると判断してサービス機器3からサービスの提供を受ける。
【選択図】 図1
Description
この発明は証明書検証システムに関するものであり、特に信頼情報を利用した証明書検証システムに関するものである。
ユーザ端末同士が交信を行うとき、一方のユーザの端末が相手ユーザの端末(携帯端末4を含む)を認証するために、公開鍵基盤(PKI:Public Key Infrastructure)における公開鍵証明書(以下、ディジタル証明書または単に証明書と称する場合もある)の検証を行う場合がある。この場合、一方のユーザの端末は、相手ユーザの端末のディジタル証明書を発行した認証局(以下、CAと称する場合もある。CA:Certificate Authority)、さらにこのCAのディジタル証明書を発行した1レベル上位のCA、さらにこの1レベル上位のCAのディジタル証明書を発行したさらに1レベル上位のCA、……というようにCAの階層構造を順次上位に向かって上記一方のユーザの端末が信頼するCAが見つかるまで辿りながら各階層のCAのディジタル証明書で構成される一連のチェーンを証明書パスとして構築する。次に構築した証明書パスを上記一方のユーザの端末が信頼するCAから逆方向に(即ち、下位に向かって)1レベルずつ順次辿りながら、全ての階層のCAにおいて各CAが発行した証明書の内容(各フィールドの値)、1レベル上位のCAによる署名、失効状態などの確認を繰り返し、証明書パスに存在するすべての証明書の正当性を検証することによって、検証対象の証明書を信頼できるかどうかの判断を行っていた(例えば、非特許文献1参照)。
また、証明書パスの検証における失効検証で、失効情報をサーバに問い合わせることによって、検証者によるCRL処理のオーバーヘッドを軽減する方法も提案されている(例えば、非特許文献2参照)。なお、CRLはCertificate Revocation Listの略称であり、失効したディジタル証明書のリストである。
さらに検証者に代わって証明書検証サーバが証明書パス構築、証明書パス検証などを実施し、その結果を検証者に返すことを可能にする仕組なども提案されている(非特許文献3、および4参照)。
IETF(Internet Engineering Task Force) pkix Working Group「Internet X.509 Public Key Infrastructure Certificate and CRL Profile」 January 1999
IETF(Internet Engineering Task Force) pkix Working Group「X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP」 June 1999
IETF(Internet Engineering Task Force) pkix Working Group「Simple Certificate Validation Protocol (SCVP)」 February 2005
IETF(Internet Engineering Task Force) pkix Working Group「DPV and DPD over OCSP」 January 2003
従来の証明書検証は上記のように構成されているが、CAの階層化やCAの信頼関係の複雑化によって証明書パスが長くなるとともに、またはCAが発行するCRLのサイズの増大によって、処理に非常に時間がかかってしまうという問題点があった。
また、失効情報をサーバに問い合わせる仕組みを利用した場合も、検証者がすべての証明書に対して失効情報を各サーバに問い合わせなくてはならず、したがって通信処理にともなう遅延が発生する、という問題点があった。
また、証明書検証サーバにすべての証明書検証処理を代行してもらう場合でも、証明書検証時に検証サーバとユーザの携帯端末4との間の通信による遅延が発生するという問題点があった。
この発明は上記のような問題点を解決するためになされたもので、証明書検証処理の遅延を少なくすることを目的とする。また、この証明書検証処理の対象を人間にとって直感的に分かりやすくなるように改善することを目的とする。
この発明に係る証明書検証システムは、
機器類の証明書を発行する認証局と、
この認証局から自分の証明書を受信して保存し、ユーザにサービスを提供するサービス機器と、
ユーザによって携帯され、データベースを保有し、上記サービス機器のサービスを利用しようとするときに、上記サービス機器から上記証明書を取得し、取得した証明書の検証処理を実行する代りに取得した証明書の信頼情報が上記データベースに登録されていないとき、この証明書が信頼できるか否かを調べ、信頼できる場合にこの旨を信頼情報として上記データベースに登録する携帯端末を備え、
上記携帯端末は、上記サービス機器から取得した証明書の信頼情報が上記データベースに登録されている場合に、上記サービス機器が信頼できると判断して上記サービス機器からサービスの提供を受けるようにしたものである。
機器類の証明書を発行する認証局と、
この認証局から自分の証明書を受信して保存し、ユーザにサービスを提供するサービス機器と、
ユーザによって携帯され、データベースを保有し、上記サービス機器のサービスを利用しようとするときに、上記サービス機器から上記証明書を取得し、取得した証明書の検証処理を実行する代りに取得した証明書の信頼情報が上記データベースに登録されていないとき、この証明書が信頼できるか否かを調べ、信頼できる場合にこの旨を信頼情報として上記データベースに登録する携帯端末を備え、
上記携帯端末は、上記サービス機器から取得した証明書の信頼情報が上記データベースに登録されている場合に、上記サービス機器が信頼できると判断して上記サービス機器からサービスの提供を受けるようにしたものである。
この発明によれば、信頼情報を一度保管すれば、次回以降の携帯端末4におけるサービス機器3の証明書の検証時に信頼情報50の有無を確認するだけでよく、時間のかかる証明書パス構築および証明書パス検証をしなくても済むので、サービス提供開始までの時間を短縮することができるという効果を奏する。
実施の形態1.
図1はこの発明の実施の形態1で用いられる証明書検証システムを示す概略図である。
図1において、認証局1は後述のサービス機器3などに公開鍵証明書を発行するサーバ計算機、検証局(CVS:Certificate Validation Server)2はディジタル証明書検証の際に必要に応じて従来の証明書検証を検証者に代わって代行するサーバ計算機、サービス機器3は場所やモノに露出あるいは埋め込まれた状態で設置され、ユーザ6の要求に応じて何らかのサービスをユーザ6に提供するマイクロコンピュータなどの専用小型計算機、携帯端末4はユーザ6が利用する携帯可能な小型計算機(携帯用パソコン、PDA、携帯電話など)、信頼情報DB5は携帯端末4に内蔵され、サービス機器の証明書の信頼情報を保管するデータベース、ユーザ6はサービス機器3が提供するサービスを利用する人間である。
図2は、この発明の全ての実施の形態で用いられ、ユーザが所持する携帯端末4の構成図である。図2において、携帯端末4はプログラムを実行することにより各種演算処理や各種制御を行うCPU401と、このCPU401が実行するプログラムを記憶しているROM402と、各種データやCPU401がプログラム実行中に発生する中間データを記憶するメモリ403と、キーボードやタッチパネルなどの操作盤404からのデータを入力する入力部405とCRTや液晶パネルなどの表示を行うモニタ部406と、モニタ部406の表示を制御する表示制御部407と、信頼情報DBを保持する補助メモリ408と、補助メモリ408の書き込み及び読み出しを行う補助メモリ制御部409と、送信信号を高周波信号に変調して送受信アンテナ411へ供給するまたは送受信アンテナ411からの高周波信号を受信してベースバンド信号に復調する無線通信制御部410と、無線通信制御部410から供給された高周波信号を電波として無線ネットワーク7へ送信または無線ネットワークから電波を受信して無線通信制御部410へ供給する送受信アンテナ411とを含んでいる。この他に必要に応じて印刷部や他のハードウェアオブションを組み込むことも可能である。バス412はCPU401、ROM402、メモリ403、入力部405、表示制御部407、補助メモリ制御部409、無線通信制御部410を接続する。なお、本発明とは関係ないので図示しないが、携帯端末4はバッテリーにより給電されており、常時給電できるようにDC電源あるいはAC電源との接続口も備えている。
CPU401は第1の制御手段を構成する。メモリ403は記憶手段を構成する。
図3は、この発明の全ての実施の形態で用いられ、サービス機器の構成図である。図3において、サービス機器3はプログラムを実行することにより各種演算処理や各種制御を行うCPU301と、CPU301が実行するプログラムを記憶しているROM302と、ディジタル証明書やサービス価格などのデータを記憶するメモリ303と、ドアなどの外部のサービス対象装置に対するCPU301からの制御信号をこのサービス対象装置に適した信号に変換(信号レベル変換、信号時間変換などの変換)し、且つこの信号をサービス対象装置に出力して開閉などのサービスを行い、このサービス対象装置からサービス完了信号を受信して内部に適した信号に変換するI/Oインタフェース部304と、送信信号を高周波信号に変換して送受信アンテナ306へ供給する、またはアンテナ306からの高周波信号を受信してベースバンドの受信信号に復調する無線通信制御部305と、無線通信制御部305からの高周波信号を電波として無線ネットワークへ送信または無線ネットワークから電波を受信して部無線通信制御部305へ出力する送受信アンテナ306と、バス307を含んでいる。バス307はCPU301、ROM302、メモリ303、I/Oインタフェース304、無線通信制御部305を接続する。なお、ネットワークとしては、インターネットを始め、無線LANやブルーツース、赤外線通信、DSRCなどを含むが、ネットワークの条件を満足するものであれば、その他のものでも構わない。また、図2、図3では、通信として無線通信のみを対象にするように構成されているが、有線の通信制御部を搭載することでインターネットなどと有線で通信することも可能である。なお、本発明とは関係ないので図示しないが、サービス機器3はバッテリーによりあるいは常時外部から給電されている。
CPU301は第2の制御手段を構成し、メモリ303は第2の記憶手段を構成する。
図4は、この発明の実施の形態1において、信頼情報DB5に保管する信頼情報50の構成を示す概略図である。図4において、信頼情報50は、サービス機器3が設置されている場所(orモノ)を一意に特定する場所またはモノ特定情報51、証明書を唯一に特定する証明書特定情報52、事前に実施した従来の証明書検証の結果“その証明書が信頼できる”旨を示す証明書検証結果53、信頼情報50の有効な期間を示す有効期間54を含んでいる。
図5は、この発明の実施の形態1における証明書検証システムの動作を説明した概略図である。次に、図1から図5を用いてシステムの動作を説明する。図5中、()で示した数字は動作の時間的順序を示している。
図5において、予め場所(またはモノ)に設置されているサービス機器3に対して認証局1からこのサービス機器3のディジタル証明書を発行し、このディジタル証明書を通信回線やインターネットなどのネットワーク7経由でサービス機器3へ送信し、サービス機器3はこのディジタル証明書を受信して保存しておく。具体的には、サービス機器3では認証局1からネットワーク7経由で送信されたディジタル証明書を送受信アンテナ306、無線通信制御装置305を介してCPU301が取得して内蔵のメモリ303に保存しておく。また、提供するサービスの価格も予めダウンロード、即ち別のサーバ計算機から無線通信により、送受信アンテナ306、無線通信制御部305を介してCPU301が取り込んだり、図示しない着脱可能な操作盤をI/Oインタフェース部304に接続して、管理者がこの着脱可能な操作盤を用いてサービス価格を入力操作したものをI/Oインタフェース部304を介してCPU301が入力したりなどして取得し、メモリ303に保存しておく。上記メモリへの保存が完了したら不要になった着脱可能な操作盤をI/Oインタフェース304から切断して取り外し、I/Oインタフェース304にサービス対象装置を接続しておく。
図5において、予め場所(またはモノ)に設置されているサービス機器3に対して認証局1からこのサービス機器3のディジタル証明書を発行し、このディジタル証明書を通信回線やインターネットなどのネットワーク7経由でサービス機器3へ送信し、サービス機器3はこのディジタル証明書を受信して保存しておく。具体的には、サービス機器3では認証局1からネットワーク7経由で送信されたディジタル証明書を送受信アンテナ306、無線通信制御装置305を介してCPU301が取得して内蔵のメモリ303に保存しておく。また、提供するサービスの価格も予めダウンロード、即ち別のサーバ計算機から無線通信により、送受信アンテナ306、無線通信制御部305を介してCPU301が取り込んだり、図示しない着脱可能な操作盤をI/Oインタフェース部304に接続して、管理者がこの着脱可能な操作盤を用いてサービス価格を入力操作したものをI/Oインタフェース部304を介してCPU301が入力したりなどして取得し、メモリ303に保存しておく。上記メモリへの保存が完了したら不要になった着脱可能な操作盤をI/Oインタフェース304から切断して取り外し、I/Oインタフェース304にサービス対象装置を接続しておく。
次に、上記のように既に認証局1から発行された証明書がサービス機器3に保存されている状態で、携帯端末4を所持するユーザ6がサービス機器3の設置されている場所を通過しようとするときの、あるいはサービス機器3が埋め込まれているモノをアクセスしたときのシステムの動作について説明する。携帯端末4を所持するユーザ6がサービス機器3の設置されている場所を通過しようとするとき、あるいはサービス機器3が埋め込まれているモノをアクセスしたとき、携帯端末4はサービス機器3からサービスを提供してもらう前に、サービス機器3が正当なものか否かを認証する。この認証を実現する為にユーザ6が所持する携帯端末4からサービス機器に対して証明書要求信号が自動的に発せられる。具体的には、携帯端末4は内蔵のタイマーにより、定期的に起動されて他端末(ここでは、サービス機器3)に対してポーリング信号を発し、その後待ち受けて他端末からの信号の有無を電解強度が所定の値以上か否かによりチェックし、電解強度が所定の値以上ならば信号を検出したと判断し、所定の値未満ならば信号を検出しなかったと判断する。信号を検出しなければ、省電力維持のために起動を停止してスリープモードに戻る。信号を検出すれば、携帯端末4は動作を継続する。サービス機器3も同様に、定期的に起動されて他端末(ここでは、携帯端末4)からの信号の有無を電解強度が所定の値以上か否かによりチェックし、電解強度が所定の値以上ならば信号を検出したと判断し、所定の値未満ならば信号を検出しなかったと判断する。信号を検出しなければ、省電力維持のために起動を停止してスリープモードに戻る。信号を検出すれば、サービス機器3は動作を継続する。
次に、サービス機器とのデータ交信を行うために、公知の技術で初期シーケンスを実施し、相手端末の識別子を確認した上で携帯端末4とサービス機器3との間で交信可能な状態になると、携帯端末4では、CPU401が証明書要求信号を生成し、バス412、無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由でサービス機器3へ送信する。サービス機器3では、携帯端末4から証明書要求信号を無線ネットワーク経由で送受信アンテナ306、無線通信制御装置305、バス307を介してCPU301が受信すると、CPU301は、バス307を介してメモリ303からディジタル証明書を読み出して、バス307、無線通信制御部305、送受信アンテナ306を介して無線ネットワーク経由で携帯端末4に送信する。携帯端末4ではこのディジタル証明書を送受信アンテナ411、無線通信制御部410、バス412を介してCPU401が取得する。次に、この証明書を検証する際、携帯端末4のCPU401は、まずバス412、補助メモリ制御部409を介して補助メモリ408の信頼情報DB5をアクセスして、サービス機器3の証明書の信頼情報50が信頼情報DB5に保管されているか否かを確認する。この場合、このサービス機器3の信頼情報50が補助メモリ408のDB5になければ、保管されていないことを示す“読出し不成功”のステータスが逆のルート即ち補助メモリ408の信頼DB5から補助メモリ制御部409、バス412を介してCPU401に取り込まれる。サービス機器3の信頼情報50が補助メモリ408のDB5にあれば、保管されていることを示す“読出し成功”のステータスと、このサービス機器3の信頼情報50が共に補助メモリ408の信頼DB5から補助メモリ制御部409、バス412を介してCPU401に取り込まれる。そこで、CPU401はこのステータスを調べ、もし信頼情報50が信頼情報DB5に保管されていれば、取り込んだ信頼情報50の有効期間を調べる。その結果、有効期間内であれば、事前に行った従来の証明書検証の結果で“その証明書が信頼できる”旨を示している(なぜならば、事前の証明書検証で信頼できると判明したサービス機器3だけに対して信頼情報50が登録されるからである)ので、この携帯端末4ではCPU401はそのサービス機器3が正当なものであると判断してこれを信頼する。
なお、以下に示す動作においても、上記と同様に携帯端末4ではCPU401と他の構成要素との間で交換される信号やデータ類は必ずバス412を介して行われ、サービス機器3と他の構成要素との間で交換される信号やデータ類は必ずバス307を介して行われるが、ここまで説明すると複雑になり、分かりにくくなるので、分かり易くするために以下の説明では“バス412を介して”という文言および“バス307を介して”という文言を省略する。
もしCPU401がDB5のアクセスによって取得したステータスに基づき“信頼情報50が信頼情報DB5に保管されていない”か、または“信頼情報50が信頼情報DB5に保管されている”が信頼情報50の有効期間54に基づき現在時点が有効期間を超過していると携帯端末4のCPU401が判断すれば、携帯端末4では、CPU401が検証局2の送信先アドレスを指定して無線制御部410、送受信アンテナ411を介して、無線ネットワーク、ネットワーク7経由で検証局(CVS)2をアクセスして検証局2に問い合わせるなどして従来の方式で証明書を検証し、その結果を逆のルート、すなわち検証局(CVS)2からネットワーク7、無線ネットワーク経由で送受信アンテナ411、無線制御部410を介してCPU401が取得し、この証明書検証結果を調べる。CPU401による証明書検証結果に基づき、証明書が信頼できると判断した場合は、その場所(またはモノ)と結びつけて信頼情報50として保管するかどうかを(ユーザ6に逐次問い合わせる、あるいは自動的に登録する、などの手段で)判断し、保管すると判断した場合には場所(またはモノ)情報をユーザが操作盤より入力操作する。また、有効期間が超過している場合には、新たな有効期間を入力操作する。これにより場所(またはモノ)情報、新たな有効期間が入力部405経由でCPU401に入力され、CPU401はこの場所(またはモノ)情報と有効期間を信頼情報50に追加した上で、追加された信頼情報50を補助メモリ制御部409を介して補助メモリ408の信頼情報DB5に保管する。
以上が携帯端末4によるサービス機器3の認証の動作である。
以上が携帯端末4によるサービス機器3の認証の動作である。
次に、携帯端末4は、このサービス機器3が提供するサービスの価格を調べるためにサービス価格要求信号をサービス機器3に送信する。具体的には以下の通りである。携帯端末4において、CPU401はこのサービス機器3によるサービスを受けることが可能か否かを調べるためにサービス価格要求信号を生成し、無線通信制御部410およびアンテナ411を介して無線ネットワーク経由でサービス機器3へ送信する。サービス機器3は、このサービス価格要求信号を携帯端末4から受信すると、サービス価格の情報を携帯端末4に送信する。具体的には、以下の通りである。サービス機器3では、このサービス価格要求信号を携帯端末4から無線ネットワーク経由で送受信アンテナ306および無線通信制御部305を介してCPU301が受信すると、CPU301はメモリ303からサービス価格の情報を読み出して無線通信制御部305および送受信アンテナ306を介して携帯端末4へ送信する。
携帯端末4では、CPU401が価格情報をサービス機器3から無線ネットワーク経由で送受信アンテナ411および通信制御部410を介して受信すると、CPU401は、DB5より読み出した信頼情報50の場所またはモノ情報51を表示制御部407経由でモニタ部406に受信した価格情報およびサービス機器3が設置されている場所(またはモノ)を表示する。これにより、ユーザ6は、サービス機器3が設置されている場所(またはモノ)を目視により確認できる。ユーザは場所が正当なものであることを目視により確認した上で、表示されたサービス価格が適当と判断したら支払い許可の旨を示す“OK”を操作盤から入力操作する。また、支払いを拒否する場合は、“NG”を操作盤から入力する。この“OK”または“NG”の情報は入力部405を介してCPU401に入力される。CPU401は入力された情報が“OK”か否かを判断し、“OK”でない場合には、サービス不可の旨を表示制御部407経由でモニタ部406に表示して処理を終了する。“OK”の場合には、サービス提供要求信号を生成し、無線通信制御部410および送受信アンテナ411を介して無線ネットワーク経由でサービス機器3へ送信する。
なお、ここでは、支払い可能か否かをユーザが判断した上でこのユーザの指示に基づいてサービス提供要求信号を生成するようにしているが、携帯端末が自動的に支払い可能か否かを調べた上でサービス提供要求信号を生成してもよい。この場合、携帯端末4において、CPU401がユーザの銀行のIPアドレスを指定して無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由で当該ユーザの銀行をアクセスして、当該ユーザの銀行口座を調べて残高を取得する。次に、CPU401は、この残高とサービス価格を比較して、残高がサービス価格未満であればサービス提供不可の旨を表示制御部407経由でモニタ部406に表示し、残高がサービス価格以上であればサービス提供要求信号を生成し、無線通信制御部410および送受信アンテナ411を介して無線ネットワーク経由でサービス機器3へ送信するようにしてもよい。
サービス機器3では、CPU301がこのサービス提供要求信号を携帯端末4から無線ネットワーク経由で送受信アンテナ306および無線通信制御部305を介して受信すると、CPU301はサービス提供可能ならばサービス提供を開始し、サービス提供が完了したら、サービス完了の信号(あるいはメッセージ)を生成し、このサービス完了の旨を示すメッセージを無線通信制御部305および送受信アンテナ306を介して無線ネットワーク経由で携帯端末4へ送信する。また、CPU301はサービス機器3の識別子と携帯端末4の識別子と提供したサービスのコードとを無線通信制御部305および送受信アンテナ306を介してネットワーク7経由でサービス機器3を管理している会社に送信する。図示しないが、サービス機器3の管理会社ではサービス機器3からこれらの情報をネットワーク7経由で受信すると、これらの情報を記憶した上で、サービス機器3の識別子に基づいて管理している複数のサービス機器のうちから、上記のサービスを提供したサービス機器3を特定し、サービスコードに基づいて提供したサービスを特定して内部に保有しているサービスと料金の対応テーブルに基づいてサービス料金を算出し、さらに、携帯端末4の識別子に基づいてこの携帯端末4の所有者であるユーザを特定する。次に、管理会社は特定したユーザを指定して公知の技術によりカード会社に料金の支払いを請求する。これにより、管理会社とカード会社と特定されたユーザの金融機関との間で、公知の技術を利用して決済処理が行われるが、この決済処理については本発明の対象外のため、詳細説明を省略する。サービス対象機器が故障していてサービス提供不可の場合には、CPU301はサービス対象装置からの完了信号が所定の時間を超えても返ってこないことをタイムアウトなどの公知の技術を用いて検知してサービス不可の信号(あるいはメッセージ)を生成し、無線通信制御部305および送受信アンテナ306を介して無線ネットワーク経由で携帯端末4に送信して処理を終了する。
携帯端末4では、サービス完了またはサービス不可の信号(あるいはメッセージ)を無線ネットワーク経由でアンテナ411および通信制御部410を介して受信すると、CPU401がこの信号(あるいはメッセージ)を調べる。この信号(あるいはメッセージ)がサービス完了の旨を示していれば、CPU401はサービス完了の旨を表示制御部407経由でモニタ部406に表示して処理を終了する。信号(あるいはメッセージ)がサービス不可の旨を示していれば、CPU401はモニタ部406に“申し訳ありませんが、サービスを提供できません。”のようなメッセージをサービス不可理由とともに表示して処理を終了する。このようにサービス不可の場合、その旨を示すメッセージが携帯端末4のモニタ部に表示されるので、ユーザは目視によりこれを確認でき、適切な対応策を講じることが可能になる。
以上の動作をフローチャートを用いて説明する。図6は、この発明の実施の形態1における携帯端末の動作を示すフローチャートである。図6において、ステップS601で、携帯端末4はサービス機器3に対して、証明書要求信号を送信する。ステップS602で、携帯端末4はサービス機器3から検証対象の証明書を取得する。ステップS603で、携帯端末4はこのサービス機器3の信頼情報50が信頼情報DB5に保管されているかどうかを確認し、すでに保管済み(保管済みの信頼情報50の証明書検証結果53は事前の証明書パス検証で成功した旨を示す)の場合はステップS604に進み、保管されていない場合はステップS614に進む。ステップS604で、信頼情報50が有効期間内か否かを調べ、信頼情報50が有効期間内である場合はステップS605に進み、有効期間を超えている場合はステップS614に進む。ステップS605で、携帯端末4はサービス価格要求信号を生成してサービス機器3に送信する。次に、ステップS606で携帯端末4はサービス機器3からサービス価格を受信する。ステップS607で携帯端末4はサービス機器3から受信したサービス価格および場所(あるいはモノ)情報を表示部に表示して支払いを許可するか否かを促す。これにより、ユーザはサービス価格及び場所を確認の上、サービス供給を受けるか否かの選択をする。サービス供給を受けると決定した場合は支払いを許可する旨の“OK”を入力操作し、サービスを受けないと決定した場合には支払いを拒絶する旨の“NG”を入力操作する。ユーザから入力された“OK”あるいは“NG”の情報は携帯端末4によりステップS608で判断され、支払い許可の場合はステップS609に進み、そうでない場合は、ステップS613でサービス不可の旨を表示した上で処理を終了する。
ステップS609で、携帯端末4はサービス提供要求信号を生成し、このサービス提供要求信号を携帯端末4の識別子と共にサービス機器3に送信する。そして、ステップS610でサービス機器3からサービス不可あるいはサービス完了信号のいずれかを受信する。そこで、ステップS611で受信した信号がサービス完了信号か否かを調べる。受信した信号がサービス完了信号ならば、ステップS612でサービス完了の旨を表示した上で処理を終了する。受信した信号がサービス完了信号でない場合、すなわちサービス不可信号を受信した場合、ステップS613に進み、サービス不可の旨をモニタ部に表示した上で処理を終了する。これにより、ユーザはサービスが提供されなかったことを知ることができ、以後適切な対応を講じることができる。
信頼情報50が信頼情報DB5に格納されていない場合又は有効期間を超えている場合、ステップS614で携帯端末4は従来方式によってサービス機器3の証明書に対して検証を実施しステップS615に進む。ステップS615で、検証結果が信頼できるか否かを調べる。証明書を信頼できる場合にはステップS616に進み、信頼できない場合にはステップS613に進む。ステップS613ではサービス不可の旨を表示して終了する。これによりユーザ6は適切な対応を講じることができる。ステップS616で、携帯端末4は、サービス機器3を信頼情報DB5に保管するかどうかをユーザ6に問い合わせる。ユーザ6は、問い合わせに対して保管を許可するか否かを回答するとともに保管を許可する場合には、サービス機器3が設置される場所(あるいはモノ)の情報と有効期間を入力操作する。携帯端末4では、ユーザ6から入力した回答が保管を許可する場合はステップS617に進み、許可しない場合は終了する。ステップS617で、携帯端末4はユーザ6が入力操作した場所(あるいはモノ)情報および有効期間を入力し、ステップS618で、場所またはモノ特定情報51と有効期間54を信頼情報50に追加する。そしてステップS619で信頼情報50を信頼情報DB5に保管しS605に進む。
図7は、この発明の実施の形態1におけるサービス機器の動作を示すフローチャートである。図7において、ステップS701で、サービス機器3は携帯端末4から証明書要求信号を受信すると、ステップS702で、サービス機器3は携帯端末4に対して予め保有している自分のディジタル証明書を送信する。次に、ステップS703で、サービス機器3は、携帯端末4からサービス価格要求信号を受信すると、ステップS704で予め保有しているサービス価格の情報を携帯端末4に送信する。ステップS705でサービス機器3は、携帯端末4からサービス提供要求信号と携帯端末4の識別子を受信すると、ステップS706で、故障などによりサービス提供が不可能か否かを判断し、サービス提供不可能ならば、ステップS710へ飛び、サービス不可信号を携帯端末4に送信して処理を終了する。サービス提供可能ならば、ステップS707へ進み、ステップS707で、サービス機器3は、サービスを提供する。そして、サービス提供が完了したらステップS708でサービス完了信号を携帯端末4に送信する。次にステップS709でサービス機器3は自分の識別子と提供したサービスのコードと携帯端末4の識別子をサービス機器3の管理会社へ送信して処理を終了する。
以上のように、信頼情報50を一度保管すれば、次回以降の携帯端末4におけるサービス機器3の証明書の検証時に信頼情報50の有無を確認するだけでよく、時間のかかる証明書パス構築および証明書パス検証をしなくても済むので、サービス提供開始までの時間を短縮することができる。
また、証明書を信頼するかどうかの情報を、場所(あるいはモノ)の情報と結びつけているので、人間にとって信頼できるかどうかを直感的に判断できるので判断がしやすくなる。
すなわち、ユーザ6がゲートなどを通過しようとするときに、このゲートを場所としてユーザ6の携帯端末4に表示できる。ユーザ6は携帯端末4に表示された場所(またはモノ)と、現在ユーザ6が通過しようとしている場所(またはモノ)とを目視で確認することにより正しいか否かを直感的に判断できる。
仮に、なりすまし者によって、信頼情報50のデータが改竄されている場合、場所またはモノ情報8が現在ユーザ6が通過しようとしている場所やアクセスしようとしているモノとは異なるのでユーザ6は視覚により異なることを即座に判断できる。
すなわち、この実施の形態によれば、ユーザ6は信頼情報データの正当性を視覚で直感的に確認できるので、場所やモノが正しいか否かの判断が早くできるという効果を奏する。
すなわち、ユーザ6がゲートなどを通過しようとするときに、このゲートを場所としてユーザ6の携帯端末4に表示できる。ユーザ6は携帯端末4に表示された場所(またはモノ)と、現在ユーザ6が通過しようとしている場所(またはモノ)とを目視で確認することにより正しいか否かを直感的に判断できる。
仮に、なりすまし者によって、信頼情報50のデータが改竄されている場合、場所またはモノ情報8が現在ユーザ6が通過しようとしている場所やアクセスしようとしているモノとは異なるのでユーザ6は視覚により異なることを即座に判断できる。
すなわち、この実施の形態によれば、ユーザ6は信頼情報データの正当性を視覚で直感的に確認できるので、場所やモノが正しいか否かの判断が早くできるという効果を奏する。
実施の形態2.
図8はこの発明に係る証明書検証システムの実施の形態2を示す概略図である。
実施の形態1では、信頼情報DB5は携帯端末4に内蔵されるように構成したが、図8のように信頼情報50を管理するサーバ計算機をネットワーク7に接続して外部からアクセスできるように構成すれば、内部資源の少ない携帯端末4で信頼情報50を保管しておかなくて済み、また信頼情報50を複数のユーザ6で共有できる。この実施の形態2で用いられる構成は、図2の構成から補助メモリ408と補助メモリ制御部409を削除した構成である。また図3の構成はこの実施の形態2でも用いられる。
図8はこの発明に係る証明書検証システムの実施の形態2を示す概略図である。
実施の形態1では、信頼情報DB5は携帯端末4に内蔵されるように構成したが、図8のように信頼情報50を管理するサーバ計算機をネットワーク7に接続して外部からアクセスできるように構成すれば、内部資源の少ない携帯端末4で信頼情報50を保管しておかなくて済み、また信頼情報50を複数のユーザ6で共有できる。この実施の形態2で用いられる構成は、図2の構成から補助メモリ408と補助メモリ制御部409を削除した構成である。また図3の構成はこの実施の形態2でも用いられる。
図9は、この発明の実施の形態2における証明書検証システムの動作を説明した概略図である。図9において、個々の携帯端末4が信頼情報50を信頼情報DB5に保管しているのではなく、サーバ計算機である信頼情報サーバ8としてネットワーク7に接続されており、携帯端末4からネットワーク7を介してアクセスできるところが、実施の形態1と異なる部分である。
図10は、この発明の実施の形態2における携帯端末4の動作を示すフローチャートである。図10において、図6と異なる点は図6のステップS603のみである。図6のステップS603では、携帯端末4内部の信頼情報DB5を参照するようにしていたが、図10では、その代わりに、ステップS1003でネットワーク7に接続された信頼情報サーバ8に信頼情報を問合せるところが、実施の形態1と異なる部分である。
サービス機器3の動作を示すフローチャートは図7と同じである。
サービス機器3の動作を示すフローチャートは図7と同じである。
この実施の形態により、実施の形態1と同様の効果に加えて、携帯端末は信頼情報DBを備える必要がないので携帯端末の小型化が可能であるという効果を奏する。
実施の形態3.
この発明の実施の形態3を適用したシステムの概略図は、実施の形態2の図8と同一である。
実施の形態2では信頼情報サーバ8をネットワーク7に接続して構成し、実施の形態1と同様に携帯端末4がサービス機器3の証明書を取得してから信頼情報50の有無を確認しているが、本実施の形態3では携帯端末4がサービス機器3から証明書を取得すると同時に、サービス機器3が事前に信頼情報サーバ8に信頼情報50の問い合わせを行った結果も取得することで、携帯端末4における証明書検証処理を軽減することができる。
この発明の実施の形態3を適用したシステムの概略図は、実施の形態2の図8と同一である。
実施の形態2では信頼情報サーバ8をネットワーク7に接続して構成し、実施の形態1と同様に携帯端末4がサービス機器3の証明書を取得してから信頼情報50の有無を確認しているが、本実施の形態3では携帯端末4がサービス機器3から証明書を取得すると同時に、サービス機器3が事前に信頼情報サーバ8に信頼情報50の問い合わせを行った結果も取得することで、携帯端末4における証明書検証処理を軽減することができる。
図11は、この発明の実施の形態3における証明書検証システムの動作を説明した概略図である。図11において、サービス機器3が事前に自分の信頼情報50を信頼情報サーバ8に問い合せ、この信頼情報50と信頼情報サーバ8の識別子と信頼情報サーバのディジタル署名とを事前照会結果として取得してメモリに保存しておき、携帯端末4からの証明書要求信号に応じて証明書とともに上記事前照会結果を携帯端末4に送るところが実施の形態2と異なる部分である。
図12は、この発明の実施の形態3における携帯端末の動作を示すフローチャートである。図10と異なる部分は、図10のステップS601とステップS602のみであり、図10のステップS601の代わりにステップS1201が実行され、図10のステップS602の代わりにステップS1202とステップS1203が実行される。
図13は、この発明の実施の形態3におけるサービス機器の動作を示すフローチャートである。図7と異なる部分は、図13のステップS1301とステップS1302のみであり、図7のステップS701の代わりにステップS1301が実行され、図7のステップS702の代わりにステップS1302が実行される。
次に異なる部分について説明する。図12において、携帯端末4ではサービス機器3の認証が完了したら、CPU401がステップS1201で証明書、および信頼情報の事前照会結果要求信号を生成して無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由でサービス機器3に送信する。
サービス機器3において、図13のステップS1301で携帯端末4から無線ネットワーク経由で送受信アンテナ306、無線通信制御部305を介してCPU301が証明書、および信頼情報の事前照会結果要求信号を受信すると、CPU301はステップS1302で信頼情報の事前照会結果をサービス機器3の証明書と共に携帯端末4へ送信する。具体的には、CPU301が信頼情報50の事前照会結果である信頼情報50と信頼情報サーバ8の識別子と信頼情報サーバ8のディジタル署名とをメモリ303から読み出して、サービス機器3の証明書と共に無線通信制御部305、送受信アンテナ306を介して無線ネットワーク経由で携帯端末4へ送信する。
携帯端末4では、ステップS1202でサービス機器3から無線ネットワーク経由で送受信アンテナ411、無線通信制御部410を介してCPU401がサービス機器3の証明書および信頼情報の事前照会結果を取得すると、CPU401はステップS1203で事前照会結果の内容および事前照会結果につけられている信頼情報サーバのディジタル署名を検証する。ここで、ディジタル署名が正しければステップS605に進み、署名が不正ならばステップS1003に飛ぶ。
図13は、この発明の実施の形態3におけるサービス機器の動作を示すフローチャートである。図7と異なる部分は、図13のステップS1301とステップS1302のみであり、図7のステップS701の代わりにステップS1301が実行され、図7のステップS702の代わりにステップS1302が実行される。
次に異なる部分について説明する。図12において、携帯端末4ではサービス機器3の認証が完了したら、CPU401がステップS1201で証明書、および信頼情報の事前照会結果要求信号を生成して無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由でサービス機器3に送信する。
サービス機器3において、図13のステップS1301で携帯端末4から無線ネットワーク経由で送受信アンテナ306、無線通信制御部305を介してCPU301が証明書、および信頼情報の事前照会結果要求信号を受信すると、CPU301はステップS1302で信頼情報の事前照会結果をサービス機器3の証明書と共に携帯端末4へ送信する。具体的には、CPU301が信頼情報50の事前照会結果である信頼情報50と信頼情報サーバ8の識別子と信頼情報サーバ8のディジタル署名とをメモリ303から読み出して、サービス機器3の証明書と共に無線通信制御部305、送受信アンテナ306を介して無線ネットワーク経由で携帯端末4へ送信する。
携帯端末4では、ステップS1202でサービス機器3から無線ネットワーク経由で送受信アンテナ411、無線通信制御部410を介してCPU401がサービス機器3の証明書および信頼情報の事前照会結果を取得すると、CPU401はステップS1203で事前照会結果の内容および事前照会結果につけられている信頼情報サーバのディジタル署名を検証する。ここで、ディジタル署名が正しければステップS605に進み、署名が不正ならばステップS1003に飛ぶ。
この実施の形態により、実施の形態2と同様の効果に加えて、携帯端末はサービス機器の事前照会結果を取得できるので、実施の形態2において、1回目には必ず実行される証明書検証処理を特別の事情以外には実行する必要がなく、従って証明書検証処理を軽減することができるという効果を奏する。
実施の形態4.
この発明の実施の形態4を適用したシステムの概略図は、実施の形態2の図8と同一である。
実施の形態2では信頼情報サーバ8をネットワーク7に接続して構成し、実施の形態1と同様に携帯端末4がサービス機器3のディジタル証明書を取得してから信頼情報50の有無を確認しており、また実施の形態3ではサービス機器3が事前に信頼情報サーバ8への照会を実施しておき、その結果を携帯端末4に送る形態で構成されているが、本実施の形態4では携帯端末4がサービス機器3からディジタル証明書を取得すると同時に、サービス機器3が事前に検証局2に証明書検証の問い合わせを行った結果も携帯端末4が取得することで、携帯端末4における証明書検証処理を省略することができる。
この発明の実施の形態4を適用したシステムの概略図は、実施の形態2の図8と同一である。
実施の形態2では信頼情報サーバ8をネットワーク7に接続して構成し、実施の形態1と同様に携帯端末4がサービス機器3のディジタル証明書を取得してから信頼情報50の有無を確認しており、また実施の形態3ではサービス機器3が事前に信頼情報サーバ8への照会を実施しておき、その結果を携帯端末4に送る形態で構成されているが、本実施の形態4では携帯端末4がサービス機器3からディジタル証明書を取得すると同時に、サービス機器3が事前に検証局2に証明書検証の問い合わせを行った結果も携帯端末4が取得することで、携帯端末4における証明書検証処理を省略することができる。
図14は、この発明の実施の形態4における証明書検証システムの動作を説明した概略図である。図14において、サービス機器3が事前に自分の証明書検証を従来方式で実施し、その結果を検証局2のディジタル署名つきで取得しておき、携帯端末4からの要求に応じて証明書とともに事前検証結果を携帯端末4に送るところが実施の形態1、または2、または3と異なる部分である。即ち、サービス機器3は事前に検証局2に対して、自分の証明書が正当なものか否かを問い合わせるためにサービス機器3の証明書と共に問い合わせ要求をネットワーク7経由で送信する。検証局2は、サービス機器3から問い合わせ要求を受信すると、サービス機器3の証明書を従来と同様の技術により検証し、その検証結果にディジタル署名を施し、サービス機器3にネットワーク7経由で返信する。サービス機器3はこれらの情報を検証局2から受信すると、メモリ303に保存する。
図15は、この発明の実施の形態4における携帯端末4の動作を示すフローチャートである。図15において、図10と異なる部分は、図10のステップS601とステップS602のみであり、図10のステップS601の代わりにステップS1501が実行され、図10のステップS602の代わりにステップS1502とステップS1503が実行される。
図16は、この発明の実施の形態4におけるサービス機器の動作を示すフローチャートである。図7と異なる部分は、図16のステップS1601とステップS1602のみであり、図7のステップS701の代わりにステップS1601が実行され、図7のステップS702の代わりにステップS1602が実行される。
次に異なる部分について説明する。図15において、ステップS1501で、CPU401がサービス機器3の証明書と証明書検証結果とを要求する要求信号を生成して無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由でサービス機器3に送信する。
サービス機器3において、図16のステップS1601で携帯端末4から無線ネットワーク経由で送受信アンテナ306、無線通信制御部305を介してCPU301が証明書と証明書検証結果とを要求する要求信号を受信すると、CPU301はステップS1602でメモリ303からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を読み出して無線通信制御部305、送受信アンテナ306を介して無線ネットワーク経由で携帯端末4へ送信する。
携帯端末4において、図15のステップS1502で、サービス機器3からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を送受信アンテナ411、無線通信制御部410を介してCPU401が受信する。さらに携帯端末4のCPU401はステップS1503で検証局2のディジタル署名を検証し、署名が正しければ証明書検証結果を参照しその証明書検証結果がOKならば、ステップS605に進み、ディジタル署名が不正か、または証明書検証結果がNGならば、ステップS1003に進む。
この実施の形態によれば、実施の形態2の効果に加え、携帯端末の処理軽減が図れるという効果を奏する。
図16は、この発明の実施の形態4におけるサービス機器の動作を示すフローチャートである。図7と異なる部分は、図16のステップS1601とステップS1602のみであり、図7のステップS701の代わりにステップS1601が実行され、図7のステップS702の代わりにステップS1602が実行される。
次に異なる部分について説明する。図15において、ステップS1501で、CPU401がサービス機器3の証明書と証明書検証結果とを要求する要求信号を生成して無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由でサービス機器3に送信する。
サービス機器3において、図16のステップS1601で携帯端末4から無線ネットワーク経由で送受信アンテナ306、無線通信制御部305を介してCPU301が証明書と証明書検証結果とを要求する要求信号を受信すると、CPU301はステップS1602でメモリ303からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を読み出して無線通信制御部305、送受信アンテナ306を介して無線ネットワーク経由で携帯端末4へ送信する。
携帯端末4において、図15のステップS1502で、サービス機器3からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を送受信アンテナ411、無線通信制御部410を介してCPU401が受信する。さらに携帯端末4のCPU401はステップS1503で検証局2のディジタル署名を検証し、署名が正しければ証明書検証結果を参照しその証明書検証結果がOKならば、ステップS605に進み、ディジタル署名が不正か、または証明書検証結果がNGならば、ステップS1003に進む。
この実施の形態によれば、実施の形態2の効果に加え、携帯端末の処理軽減が図れるという効果を奏する。
実施の形態5.
この発明の実施の形態5を適用したシステムの概略図は、実施の形態1の図1と同一である。
この発明の実施の形態5を適用したシステムの概略図は、実施の形態1の図1と同一である。
実施の形態5では、サービス機器3が事前に検証局2に問合せるなどして自分の証明書の検証を実施しておき、その結果を証明書とともに携帯端末4に送信することにより、ユーザ6がはじめてサービス機器3にアクセスした場合でも証明書検証を実施することなく信頼するかどうかの判断を行うことができる。
図17は、この発明の実施の形態5における証明書検証システムの動作を説明した概略図である。図17において、サービス機器3が事前に検証局2に証明書検証を依頼するところが実施の形態1と異なる部分である。即ち、サービス機器3は事前に検証局2に対して、自分の証明書が正当なものか否かを問い合わせるためにサービス機器3の証明書と共に問い合わせ要求をネットワーク7経由で送信する。検証局2は、サービス機器3から問い合わせ要求を受信すると、サービス機器の証明書を従来方式の技術により検証し、その結果にディジタル署名を施し、サービス機器3にネットワーク7経由で返信する。サービス機器3はこれらの情報を検証局2から受信すると、メモリ303に保存する。
図18は、この発明の実施の形態5における携帯端末4の動作を示すフローチャートである。図18において、ステップS1502で証明書の事前検証結果を取得する部分、ステップS1503で事前検証結果の内容および事前検証結果につけられた検証局2の署名を検証する部分が実施の形態1と異なる部分である。
サービス機器3の動作を示すフローチャートは図16と同じである。
次に異なる部分について説明する。図18において、ステップS1501で、CPU401がサービス機器3に対してサービス機器3の証明書と証明書検証結果とを要求する要求信号を生成して無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由でサービス機器3に送信する。
サービス機器3において、図16のステップS1601で携帯端末4から無線ネットワーク経由で送受信アンテナ306、無線通信制御部305を介してCPU301が証明書と証明書検証結果とを要求する要求信号を受信すると、CPU301はステップS1602でメモリ303からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を読み出して無線通信制御部305、送受信アンテナ306を介して無線ネットワーク経由で携帯端末4へ送信する。
携帯端末4において、図15のステップS1502で、サービス機器3からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を送受信アンテナ411、無線通信制御部410を介してCPU401が受信する。さらに携帯端末4のCPU401はステップS1503で検証局2のディジタル署名を検証し、署名が正しければ証明書検証結果を参照しその証明書検証結果がOKならば、CPU401はサービス機器3が信頼できると判断して、ステップS605に進む。ディジタル署名が不正か、または証明書検証結果がNGならば、ステップS1003に進む。 この実施の形態によれば、実施の形態1の効果に加え、携帯端末の処理軽減が図れるという効果を奏する。また、証明書検証処理を軽減することができるという効果を奏する。
サービス機器3の動作を示すフローチャートは図16と同じである。
次に異なる部分について説明する。図18において、ステップS1501で、CPU401がサービス機器3に対してサービス機器3の証明書と証明書検証結果とを要求する要求信号を生成して無線通信制御部410、送受信アンテナ411を介して無線ネットワーク経由でサービス機器3に送信する。
サービス機器3において、図16のステップS1601で携帯端末4から無線ネットワーク経由で送受信アンテナ306、無線通信制御部305を介してCPU301が証明書と証明書検証結果とを要求する要求信号を受信すると、CPU301はステップS1602でメモリ303からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を読み出して無線通信制御部305、送受信アンテナ306を介して無線ネットワーク経由で携帯端末4へ送信する。
携帯端末4において、図15のステップS1502で、サービス機器3からサービス機器3の証明書と証明書検証結果と検証局2の識別子と検証局2のディジタル署名を送受信アンテナ411、無線通信制御部410を介してCPU401が受信する。さらに携帯端末4のCPU401はステップS1503で検証局2のディジタル署名を検証し、署名が正しければ証明書検証結果を参照しその証明書検証結果がOKならば、CPU401はサービス機器3が信頼できると判断して、ステップS605に進む。ディジタル署名が不正か、または証明書検証結果がNGならば、ステップS1003に進む。 この実施の形態によれば、実施の形態1の効果に加え、携帯端末の処理軽減が図れるという効果を奏する。また、証明書検証処理を軽減することができるという効果を奏する。
1 認証局、2 検証局、3 サービス機器、4 携帯端末、5 信頼情報DB、6 ユーザ、7 ネットワーク、8 信頼情報サーバ、50 信頼情報、301 CPU、302 ROM、303 メモリ、304 I/Oインタフェース、305 無線通信制御部、306 送受信アンテナ、 307 バス、 401 CPU、402 ROM、403 メモリ、404 操作盤、405 入力部、406 モニタ部、407 表示制御部、408 補助メモリ、 409 補助メモリ制御部、410 無線通信制御部、411 送受信アンテナ、 412 バス。
Claims (6)
- 機器類の証明書を発行する認証局と、
この認証局から自分の証明書を受信して保存し、ユーザにサービスを提供するサービス機器と、
ユーザによって携帯され、データベースを保有し、上記ユーザが上記サービス機器のサービスを利用しようとするときに、上記サービス機器から上記証明書を取得し、上記証明書の信頼情報が上記データベースに登録されていないとき、この証明書が信頼できるか否かを調べ、信頼できる場合にこの旨を信頼情報として上記データベースに登録する携帯端末とを備え、
上記携帯端末は、上記サービス機器の信頼性を調べるとき、上記サービス機器から取得した証明書の検証処理を実行する代りに、上記取得した証明書の信頼情報が上記データベースに登録されている場合に、上記サービス機器が信頼できると判断して上記サービス機器からサービスの提供を受けることを特徴とする証明書検証システム。 - 機器類の証明書を発行する認証局と、
サーバ計算機と、
上記認証局から自分の証明書を受信して保存し、ユーザにサービスを提供するサービス機器と、
ユーザによって携帯され、上記ユーザが上記サービス機器のサービスを利用しようとするときに、上記サービス機器から上記証明書を取得し、取得した証明書の信頼情報が上記サーバ計算機に登録されていないとき、この証明書が信頼できるか否かを調べ、信頼できる場合にこの旨を信頼情報として上記サーバ計算機に登録する携帯端末とを備え、
上記携帯端末は、上記サービス機器の信頼性を調べるとき、上記サービス機器から取得した証明書の検証処理を実行する代りに、上記取得した証明書の信頼情報が上記サーバ計算機に登録されている場合に、上記サービス機器が信頼できると判断して上記サービス機器からサービスの提供を受けることを特徴とする証明書検証システム。 - 上記サービス機器は事前に上記サーバ計算機に対して上記信頼情報を登録しているか否かの照会を行い、上記サーバ計算機から上記照会の結果と上記サーバ計算機のディジタル署名とを事前照会結果として受信して保存しておき、
上記携帯端末は上記サービス機器のサービスを利用しようとするとき、上記サービス機器から上記保存されている事前照会結果を取得し、この事前照会結果に基づいて上記サービス機器が信頼できると判断した場合に上記サービス機器からサービスの提供を受けることを特徴とする請求項2に記載の証明書検証システム。 - 検証局を備え、
この検証局は事前に上記サービス機器の証明書の検証を行い、この検証の結果と検証局のディジタル署名とを事前検証結果として上記サービス機器に送信し、
上記サービス機器は上記検証局からの事前検証結果を受信して保存しておき、
上記携帯端末は上記サービス機器のサービスを利用しようとするとき、上記サービス機器から上記保存されている事前検証結果を取得し、この事前検証結果に基づいて上記サービス機器が信頼できると判断した場合に上記サービス機器からサービスの提供を受けることを特徴とする請求項1または請求項2に記載の証明書検証システム。 - 上記携帯端末は、上記サービス機器の信頼情報を登録するとき上記サービス機器が設置される場所の情報を記憶し、
上記サービス機器が信頼できると判断したときに、上記サービス機器からサービスの提供を受ける前に上記場所情報を表示してユーザに確認させることを特徴とする請求項1から請求項4のいずれかに記載の証明書検証システム。 - 上記携帯端末は、上記サービス機器が設置されるモノの情報を記憶し、
上記サービス機器が信頼できると判断したときに、上記サービス機器からサービスの提供を受ける前に上記モノの情報を表示してユーザに確認させることを特徴とする請求項1から4のいずれかに記載の証明書検証システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005246219A JP2007060539A (ja) | 2005-08-26 | 2005-08-26 | 証明書検証システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005246219A JP2007060539A (ja) | 2005-08-26 | 2005-08-26 | 証明書検証システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007060539A true JP2007060539A (ja) | 2007-03-08 |
Family
ID=37923579
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005246219A Pending JP2007060539A (ja) | 2005-08-26 | 2005-08-26 | 証明書検証システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007060539A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010239443A (ja) * | 2009-03-31 | 2010-10-21 | Brother Ind Ltd | 通信装置及びコンピュータプログラム |
JP2010283575A (ja) * | 2009-06-04 | 2010-12-16 | Konica Minolta Business Technologies Inc | 認証用プログラム、認証用装置および認証方法 |
JP2011171946A (ja) * | 2010-02-17 | 2011-09-01 | Toshiba Corp | 携帯可能電子装置、携帯可能電子装置の制御方法及びicカード |
JP2014078911A (ja) * | 2012-10-12 | 2014-05-01 | Renesas Electronics Corp | 車載通信システム |
US11223934B2 (en) | 2016-12-14 | 2022-01-11 | Autonetworks Technologies, Ltd. | Road-vehicle communication system, roadside communication apparatus, in-vehicle communication apparatus, and road-vehicle communication method |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001134181A (ja) * | 1999-11-02 | 2001-05-18 | Nippon Telegr & Teleph Corp <Ntt> | 公開鍵証明証の有効性確認システム及びその方法並びにそのプログラムを記録した媒体 |
WO2002087149A1 (fr) * | 2001-04-19 | 2002-10-31 | Ntt Docomo, Inc. | Systeme de communication de terminaux |
JP2003296277A (ja) * | 2002-03-29 | 2003-10-17 | Fuji Xerox Co Ltd | ネットワーク装置、認証サーバ、ネットワークシステム、認証方法 |
JP2005165976A (ja) * | 2003-12-05 | 2005-06-23 | Toshiba Solutions Corp | サービス提供システム、方法、プログラム及び商品販売システム |
-
2005
- 2005-08-26 JP JP2005246219A patent/JP2007060539A/ja active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001134181A (ja) * | 1999-11-02 | 2001-05-18 | Nippon Telegr & Teleph Corp <Ntt> | 公開鍵証明証の有効性確認システム及びその方法並びにそのプログラムを記録した媒体 |
WO2002087149A1 (fr) * | 2001-04-19 | 2002-10-31 | Ntt Docomo, Inc. | Systeme de communication de terminaux |
JP2003296277A (ja) * | 2002-03-29 | 2003-10-17 | Fuji Xerox Co Ltd | ネットワーク装置、認証サーバ、ネットワークシステム、認証方法 |
JP2005165976A (ja) * | 2003-12-05 | 2005-06-23 | Toshiba Solutions Corp | サービス提供システム、方法、プログラム及び商品販売システム |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010239443A (ja) * | 2009-03-31 | 2010-10-21 | Brother Ind Ltd | 通信装置及びコンピュータプログラム |
JP2010283575A (ja) * | 2009-06-04 | 2010-12-16 | Konica Minolta Business Technologies Inc | 認証用プログラム、認証用装置および認証方法 |
JP2011171946A (ja) * | 2010-02-17 | 2011-09-01 | Toshiba Corp | 携帯可能電子装置、携帯可能電子装置の制御方法及びicカード |
JP2014078911A (ja) * | 2012-10-12 | 2014-05-01 | Renesas Electronics Corp | 車載通信システム |
US11223934B2 (en) | 2016-12-14 | 2022-01-11 | Autonetworks Technologies, Ltd. | Road-vehicle communication system, roadside communication apparatus, in-vehicle communication apparatus, and road-vehicle communication method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105608577B (zh) | 实现不可否认性的方法及其支付管理服务器和用户终端 | |
JP4800377B2 (ja) | 認証システム、ce機器、携帯端末、鍵証明発行局および鍵証明取得方法 | |
EP3308499B1 (en) | Service provider certificate management | |
JP2019508763A (ja) | ローカルデバイス認証 | |
US11042954B2 (en) | System and method for communication between devices | |
EP2518659A1 (en) | User authentication method, user authentication system, and portable communications terminal | |
JP6894160B1 (ja) | スマートコントラクトに基づいた利用権情報処理装置、利用権情報処理システム、および利用権情報処理方法 | |
CN110601858B (zh) | 证书管理方法及装置 | |
US7797531B2 (en) | Wireless ad-hoc communication system, terminal, method for suggesting issuance of attribute certificate and method for requesting issuance of attribute certificate in the terminal, and program for causing the terminal to execute the method | |
CN104574101B (zh) | 一种用于验证电子券的方法、设备与系统 | |
CN115633356B (zh) | 基于x509数字证书申请v2x数字证书的方法和系统 | |
JP2017073611A (ja) | 情報処理システム、無線通信チップ、周辺機器、サーバ、アプリケーションプログラム、および情報処理方法 | |
JP6567939B2 (ja) | 情報処理システム、周辺機器、無線通信チップ、アプリケーションプログラム、および情報処理方法 | |
JP2007060539A (ja) | 証明書検証システム | |
US20080082818A1 (en) | Symmetric key-based authentication in multiple domains | |
CN103793819A (zh) | 交易系统、方法、电子签名工具和网络银行服务器的认证方法 | |
JP2019012561A (ja) | 認証システム、認証サーバ、認証方法及び認証プログラム | |
JP5485063B2 (ja) | 認証システム | |
CN1885768B (zh) | 一种环球网认证方法 | |
JP2017073609A (ja) | 周辺機器、無線通信チップ、アプリケーションプログラム、情報処理システム、および情報処理方法 | |
EP1610246A1 (en) | Information processing system, information processing device, method, and program | |
KR20180039037A (ko) | 온라인 서비스 서버와 클라이언트 간의 상호 인증 방법 및 시스템 | |
CN113840223B (zh) | 位置定位方法、装置、终端及网络设备 | |
KR20140098028A (ko) | 다중 디바이스 및 플랫폼을 위한 접속 인증 방법 | |
JP2005318269A (ja) | 電子証明書管理システム、電子証明書管理方法、及び、サーバ |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080528 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110218 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110301 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20110719 |