JP2005020536A - Electronic data signature device and program for signature device - Google Patents

Electronic data signature device and program for signature device Download PDF

Info

Publication number
JP2005020536A
JP2005020536A JP2003184655A JP2003184655A JP2005020536A JP 2005020536 A JP2005020536 A JP 2005020536A JP 2003184655 A JP2003184655 A JP 2003184655A JP 2003184655 A JP2003184655 A JP 2003184655A JP 2005020536 A JP2005020536 A JP 2005020536A
Authority
JP
Japan
Prior art keywords
electronic
signature
certificate
data
electronic data
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
Application number
JP2003184655A
Other languages
Japanese (ja)
Inventor
Koji Nishida
廣治 西田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fuji Electric Co Ltd
Original Assignee
Fuji Electric Holdings Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fuji Electric Holdings Ltd filed Critical Fuji Electric Holdings Ltd
Priority to JP2003184655A priority Critical patent/JP2005020536A/en
Publication of JP2005020536A publication Critical patent/JP2005020536A/en
Pending legal-status Critical Current

Links

Images

Abstract

<P>PROBLEM TO BE SOLVED: To totally manage two or more kinds of electronic certificates as a set including a public key and a private key, and improve the reliability and safety of an electronic signature. <P>SOLUTION: The device includes a means 2 to store two or more kinds of electronic certificates together with data of an administrator and an access enable person for every certificate, a means 3 to confirm that the signature request person is the access enable person stored in the means 2 responding to input of data for the signature request person and a target certification person to use the signature, and a means 4 to perform a electronic signature for the inputted electronic data using the object certification after the confirmation. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

【0001】
【発明の属する技術分野】
本発明は電子データに対する電子署名方式に係わり、更に詳しくは公開鍵基盤(PKI)に基づいて、例えば通信の信頼性の確保のために、電子データに対する電子署名を行なう電子データ署名装置、およびその装置において用いられるプログラムに関する。
【0002】
【従来の技術】
公開鍵のシステムを利用して、データの暗号化や通信データに対する電子署名を行なうことによって、データの信頼性を高める公開鍵基盤PKI(パブリック・キー・インフラストラクチャ)が利用されている。
【0003】
図14はこのような公開鍵を利用した電子署名方式の従来例の説明図である。従来は、認証局から発行された公開鍵と秘密鍵を含むセットとしての電子証明書(ディジタル証明書)がパソコン51、ICカード52、またはサーバ53の内部に保存され、これを用いて電子データに対する電子署名が行なわれ、その電子データは例えばインターネット54を介して相手先のサーバ/クライアント55に送られていた。
【0004】
すなわち認識局から発行された公開鍵と秘密鍵を含むセットとしての電子証明書が、パソコン51、またはICカード52内に保存された場合には、それらのユーザによって秘密鍵を含む電子証明書の個人的管理が行なわれているにすぎなかった。またサーバ53に保存されている場合でも、一般に複数の電子証明書の管理は統一的に行なわれていなかった。
【0005】
従って複数の電子証明書を管理する場合には、パソコン51内に複数の電子証明書を格納して個人的に管理を行なうか、ICカード52を複数枚持つか、複数のサーバによって管理するかなどの方法をとらざるを得なかった。
【0006】
このような電子署名などに関連する従来技術として、次のような文献がある。
【0007】
【特許文献1】
特開2000−224164号公報
「複数の暗号アルゴリズムを同時にサポートする装置」
【特許文献2】
特開2002−171289号公報
「ポリシーサーバ、プロキシーおよびルータ」
【特許文献3】
特開2002−207427号公報
「公開鍵証明書発行システム、公開鍵証明書発行方法、および情報処理装置、情報記録媒体、並びにプログラム記憶媒体」
【非特許文献1】
http://job8.nikki.ne.jp/companyarticle/79773/,日本ベリサイン社「ローミングサービス」(2002.7 同社 NEWS RELEASE)
特許文献1には、1度に1つの暗号化アルゴリズムしかサポートできないという欠点を持つX.509 証明書を、同時に複数の暗号アルゴリズムをサポートできるようにする技術が開示されている。
【0008】
特許文献2では、ポリシー制御されたネットワークにおいて同一の機能を実現するためのネットワーク操作法がベンダ毎、または機器毎に異なっている時にも、同一のポリシーによって全ての機器を制御できるようにする技術が開示されている。
【0009】
特許文献3には、例えばネットワークを介したデータ通信におけるセキュリティを確保するために、異なる署名アルゴリズムの処理が可能なデバイスの間で、相互に公開鍵証明書の検証を可能とする技術が開示されている。
【0010】
非特許文献1には、システム開発/ソフトニュースとして、電子証明書とその利用に必要な秘密鍵をサーバ側に保存し、どの端末からでも特別なハードウエアを購入することなく、電子証明書を利用することができるディジタルトラストサービスの提供が報告されている。
【0011】
【発明が解決しようとする課題】
しかしながら、このような従来技術においては、公開鍵、秘密鍵、および電子証明書のセットが個別に管理されている場合には、管理上の安全性の問題や、複数の電子証明書を管理する煩雑さの問題や、管理のためのコストアップなどの問題点が発生する。
【0012】
またこのようなセットを一括して管理した場合にも、複数のPKI証明書、秘密鍵、公開鍵のセットについて、それぞれIDやパスワードを設定すると、それらの管理が面倒となり、実際の署名操作が煩雑になるという問題点があった。
【0013】
さらに証明書の有効期限が切れる前に、電子データに対する新しい再署名が必要となるが、再署名すべき電子データが大量の場合には、個人的に署名要求を処理することが困難であるという問題点もあった。
【0014】
本発明の課題は、上述の問題点に鑑み、電子証明書、秘密鍵、公開鍵の複数セットを一括して管理し、電子データに対する署名と暗号化を行なうことにより、電子証明書の管理レベルを上げ、その安全性を向上させることと、証明書の有効期限が切れる前の電子データに対する再署名においては、例えばアプリケーション側からの自動的な署名要求を可能とすることによって、大量の電子署名の処理を簡単化することである。
【0015】
【課題を解決するための手段】
図1は本発明の電子データ署名装置の原理構成ブロック図である。同図において電子データ署名装置1は、電子証明書記憶手段2、アクセス制御手段3、および署名処理手段4を備える。
【0016】
電子証明書記憶手段2は、公開鍵基盤の複数種類の電子証明書、例えば公開鍵と秘密鍵とその他の証明書部分を含む電子証明書を、各証明書毎の管理者とアクセス可能者とを示すデータと共に記憶するものである。
【0017】
アクセス制御手段3は、電子データと共に入力される署名要求者のデータと、署名に使用すべき電子証明書を指定するデータを含む署名要求に対応して、署名要求者が電子証明書記憶手段2に記憶されている電子証明書の正当なアクセス可能者であることを確認するものであり、署名処理手段4はその確認の後で、指定された電子証明書を用いて、入力された電子データに対する電子署名を実行するものである。
【0018】
発明の実施の形態においては、電子データ署名装置において、証明書毎の鍵管理者とアクセス可能者との両方の合意に基づいて、電子証明書記憶手段2への証明書の登録、更新、および削除を行なう証明書登録手段を備えることもできる。
【0019】
また実施の形態においては、電子データ署名装置に対応して、電子証明書記憶手段2に記憶されているアクセス可能者を示すデータと同一のデータ、または異なるデータに基づいて、電子データ署名装置に対するアクセスの可否を認証する認証装置を備えることもできる。
【0020】
また実施の形態においては、前述の署名要求者として電子データ署名装置の管理者が指定され、アプリケーション側から与えられる署名要求に対応して、アクセス制御手段3が正当なアクセス可能者の確認を行なうことも可能であり、これによってアプリケーション側から与えられる大量の署名要求を自動的に処理することが可能となる。
【0021】
また本発明の電子署名装置用プログラムとして、電子データと共に入力される署名要求者のデータと、使用すべき電子証明書を指定するデータとを含む電子署名要求を受け取り、公開鍵基盤の複数種類の電子証明書を、その複数の各証明書毎の管理者とアクセス可能者とを示すデータと共に記憶する電子証明書記憶装置の記憶内容を参照し、署名要求者が正当なアクセス可能者であることを確認する手順と、その確認後に、指定された電子証明書を用いて、入力された電子データに対する電子署名を実行する手順とを計算機に実行させるプログラムが用いられ、またこのプログラムを格納した計算機読出し可能可搬型記憶媒体が用いられる。
【0022】
以上のように本発明によれば、公開鍵と秘密鍵とを含むセットとしての電子証明書の複数種類が、各証明書毎の管理者とアクセス可能者とを示すデータと共に一括して管理される。
【0023】
【発明の実施の形態】
図2は、本発明の電子データ署名装置の実施形態としてのPKI鍵管理サーバ10が使用される、電子データ署名方式の構成ブロック図である。同図においてPKI鍵管理サーバ10は、このサーバ10へのアクセスの可否を判定する認証サーバ11と共に、電子データに対する署名動作において基本的に重要な役割を果たすものである。
【0024】
例えばEC(電子商取引)クライアント12からの署名申請がECシステム13になされ、決済の結果としての署名要求がPKI鍵管理サーバ10に送られる。あるいはクライアント14からの署名要求がPKI鍵管理サーバ10に送られる。
【0025】
PKI鍵管理サーバ10は、要求元としてのクライアントに自サーバ10へのアクセス権限があるか、すなわち一般的に電子署名の要求を行なう権限を持つかどうかを認証サーバ11に問い合わせ、認証サーバ11はデータベース15の内容によってそれを判定する。データベース15には、PKI鍵管理サーバ10へのアクセス可能者のIDとパスワードが格納されており、認証サーバ11はこれらの内容を用いて署名を要求したクライアントにPKI鍵管理サーバ10へのアクセス権限があるか否かを確認する。
【0026】
アクセス権限がある場合には、PKI鍵管理サーバ10は後述する証明書鍵保管データベースに保存されている複数の電子証明書(公開鍵と秘密鍵を含むセット)のうちで、クライアント側から指定されたものを選択し、クライアントがその証明書へのアクセス権限があるか否かを更に確認し、権限があれば電子データに対する電子署名と暗号化を行い、相手先のサーバ/クライアント16に基幹LANやイントラネット(WAN)を経由し、更にインターネットやLG(ローカルガバメント、地方自治体)WANなどを介して送ると共に、必要に応じて原本保存サーバ17に電子データの原本を送付して保存させる。
【0027】
なおPKI鍵管理サーバ10と認証サーバ11、原本保存サーバ17、および各クライアントの間では、暗号伝送や、基幹LAN、またはイントラネット、WANなどの閉じたネットワークを利用して、データ伝送の安全性を確保することにする。
【0028】
図3は本実施形態における電子データ署名方式の基本的な処理フローチャートである。同図において処理が開始されると、まずステップS1で認証サーバ11からのアクセス可能の確認通知が受け取られ、ステップS2で対象となる電子証明書への署名要求者のアクセス権限が確認され、ステップS3で対象証明書が取り出され、電子データに対する電子署名が行われ、ステップS4で原本保存サーバ17への原本保存処理が行なわれ、ステップS5で電子署名付の電子データが相手先サーバ/クライアント16に送付されて、処理を終了する。
【0029】
図4はPKI鍵管理サーバ10におけるソフトウエア構成の説明図である。同図において、PKI鍵管理サーバ10には証明書鍵保管データベース20が備えられており、このデータベース20には後述する証明書鍵保管テーブル、証明書鍵アクセス管理テーブル、およびシステム管理テーブルの基本的に3種類のテーブルが格納されている。
【0030】
図4において鍵保管処理部21は、G(ガバメント)PKIなどの認証局から発行された証明書の登録、削除、および更新を行なうものである。その処理は、証明書毎の管理者による指示、または証明書管理者と証明書に対するアクセス可能者(所有者)との合意(電子決裁、すなわちワークフローによる合意)に基づいて行なわれる。また鍵保管処理部21は証明書毎のアクセス可能者のID、パスワードの設定、変更、削除を行なう。
【0031】
アクセス制御処理部22は、図2で説明した認証サーバ11のデータベース15に格納されているPKI鍵管理サーバ10へのアクセス可能者のデータによる確認結果と、証明書鍵アクセス管理テーブルに格納されている証明書アクセス可能者を示すデータとを用いて、電子証明書へのアクセスの制御を行なう。両方のアクセス可能者として署名の要求者が登録されていると判定されると次の証明書選択処理部23が起動される。
【0032】
証明書選択処理部23は、アクセス制御処理部22によってアクセスが承認され、署名要求者によって指定された電子証明書を証明書鍵保管テーブルから選択し、電子署名処理部24は選択された電子証明書を用いて、入力された電子データに対する電子署名を実行する。
【0033】
送受信・原本保存処理部25は、図2における相手先サーバ/クライアント16への電子署名付電子データの送信と、原本保存サーバ17への原本保存処理を実行する。原本保存処理では保存のレベルとして暗号化保存+署名保存、平文保存+署名保存、平文保存、保存なしなどの設定された保存レベルに対応した保存を、原本保存サーバ17に実行させる。原本保存サーバ17は保存した電子データの参照を可能とする。
【0034】
すなわち原本保存サーバ17は文書の原本の完全性、機密性、見読性を保証するものであり、これによって署名付き電子データの紛失防止、署名時刻の証明、長期にわたるデータの参照などが可能となる。
【0035】
アクセスログ処理部26は、PKI鍵管理サーバ10へのアクセス、証明書鍵保管データベース20に保存されている証明書へのアクセス、および相手先サーバ/クライアント16への電子データ送信などについてのログをとるものであり、詳細ログ、主要データログ、ログなしなど、設定されたレベルに対応して、ログデータを収集して保存するものである。このログデータも必要に応じて暗号化される。
【0036】
署名検証処理部27は、電子署名がなされた電子データの検証を行なうものであり、電子データの改ざんの有無を電子データに対するハッシュ値と、電子署名を公開鍵で復号化した結果の値とを比較して検証するものである。この検証によって、PKI鍵管理サーバ10によって電子署名が成された電子データが改ざんされていないことを証明できる。
【0037】
なお、特許請求の範囲の請求項1,3における電子証明書記憶手段は図4の証明書鍵保管データベース20内の証明書鍵保管テーブルに、アクセス制御手段はアクセス制御処理部22に、署名処理手段は電子署名処理部24に、また証明書登録手段は鍵保管処理部21に相当する。
【0038】
図5は、図4の証明書鍵保管データベース20内に格納されている、証明書鍵保管テーブルの格納内容の例である。同図において証明書IDと証明書名称とは、第3者機関としての認証局にそれぞれ対応する一意のものであり、証明書ID=1に対して証明書名称は例えばLGPKIとなっており、ID=2に対しては証明書名称はGPKIとなっており、ID=3に対しては証明書名称は例えば(認証)サービス会社Aとなっている。
【0039】
個別IDと本体、および秘密鍵は個々の証明書に対応するものであり、LGPKIによって発行された証明書として、個別IDが001と002にそれぞれ対応する公開鍵を含む本体と秘密鍵とが格納されている。
【0040】
またGPKIによって発行された証明書として、個別IDとして011および012を持つ証明書のそれぞれに対する本体と秘密鍵とが格納されている。
ここで例えばGPKIによって発行された個別IDが011の証明書に対しては、その証明書名称がGPKIであることが明白であり、個別IDを001とすることも可能である。
【0041】
なおここでは、証明書IDと証明書名称とが同じ証明書のそれぞれについて、個別ID、本体、および秘密鍵がテーブル内でまとめられて格納されているが、必ずしもそのように格納する必要はなく、例えばテーブル内で2行目と3行目を入れ替えることも当然可能である。
【0042】
ここでPKI証明書、公開鍵、および秘密鍵のセットは証明書鍵管理者によって、ITU(国際電気通信連合)の標準規約X.509のフォーマットに従って格納される。
【0043】
なお、後述するように証明書鍵保管テーブルへの秘密鍵を含む電子証明書の登録、更新、削除を証明書鍵管理者のみに許すか、あるいはその管理者と電子証明書の所有者との合意の条件でしか許さないことにすれば、証明書所有者へのなりすましによる秘密鍵の改ざんや削除、不正な秘密鍵の登録などを防止できる。
【0044】
図6は証明書鍵保管データベース20内の証明書鍵アクセス管理テーブルの格納内容の例である。本実施形態では、例えば証明書ID、すなわち証明書名称に対応してそれぞれ鍵管理者が設けられるものとし、例えば証明書ID=1に対する証明書鍵管理者のIDは1234であり、対応するパスワードも格納されている。
【0045】
そして図5の証明書鍵保管テーブルに格納されている個別IDを持つ電子証明書へのアクセス可能者のIDとパスワードとが、ここでは証明書ID毎にまとめられて格納されている。
【0046】
例えば証明書IDとして1を持つLGPKIによって発行された証明書のうち、個別IDとして001を持つ証明書に対しては、アクセス可能者のIDが4567であり、002を持つ証明書へのアクセス可能者のIDが3456であることが示され、またこの3456をIDとして持つアクセス可能者は同時に証明書IDが2、すなわちGPKIによって発行された個別IDとして011を持つ電子証明書に対してもアクセス可能であることが示されている。
【0047】
図7〜図9は、証明書鍵保管データベース20内のシステム管理テーブルを構成する3つのテーブルの説明図である。図7はシステムおよびログ管理者テーブルであり、図2のPKI鍵管理サーバ10自体をシステムとして管理するシステム管理者のIDとパスワード、図4のアクセスログ処理部26によるログ処理を管理するログ管理者のIDとパスワードとが格納されている。本実施形態ではリスクを分散させるために、システム管理者(サーバ管理者)とログ管理者とは別に設けるものとする。またサーバ管理者や証明書鍵管理者の数を限定することによって、教育訓練によるセキュリティー意識向上が容易となる。
【0048】
図8はログレベル管理テーブルの格納内容の例である。同図においては、アクセスの種別に対応してログレベルが設定されている。まず認証サーバ11によって認証されるPKI鍵管理サーバ10自体へのサーバアクセスログについては主要データログ、電子証明書そのものへのアクセスに対しては詳細ログ、相手先サーバ/クライアントへのデータ送付についてはログなしが設定されている。
【0049】
このようにアクセスやデータ送付についてのログを取得することにより、データ改ざん、盗聴、なりすましなどの不正が成された場合にも記録が保存され、不正の有無やその内容、すなわち誰が、いつ、何に対して不正を行なったかを特定できる。
【0050】
図9は、図2における原本保存サーバ17への保存レベルを設定する、原本管理テーブルの格納内容の例である。ここでは個別処理、例えば図2においてECクライアント12やクライアント14から個別に要求される電子データ署名の処理に対しては、暗号化保存+署名保存のレベルが、自動処理、すなわち後述するように例えばすでに署名がなされている電子データのうちで、電子署名の有効期限が切れるために、例えばアプリケーション側からの要求に対応して再び電子署名の処理を行なう自動処理に対応しては平文保存+署名保存のレベルが設定されている。
【0051】
図10は電子署名処理の詳細フローチャート(その1)である。同図において、署名対象電子データ、使用すべき証明書名称とその個別ID、署名要求者(IDとパスワードを含む)、データの送付先、および必要に応じて原本管理レベルの入力に対して処理が開始される。なお原本管理レベルは入力電子データの個々に対して、例えば図9と異なるレベルが設定される場合に入力データとして与えられる。
【0052】
まずステップS11で、署名要求者にPKI鍵管理サーバ10へのアクセス権限があるか否かが、認証サーバ11側でデータベース15の内容を用いて確認され、アクセスログがとられ、ステップS12で指定された証明書に対応するアクセス権限が署名要求者にあるか否かが確認され、対象証明書の選択が行なわれる。このアクセス権限の確認は、図6の証明書鍵アクセス管理テーブルの内容を用いて行なわれる。
【0053】
このように、PKI鍵管理サーバ10そのものへのアクセス権限の確認と、証明書に対するアクセス権限の確認のステップが順次実行されることによって、結果的に2つの確認条件のANDがとられ、電子署名が実行されることになる。
【0054】
この2つのアクセス権限の確認において用いられるIDとパスワードについては、署名要求者が通常使用しているIDとパスワードをそのまま2つの確認に共通して用いることも可能であるが、例えば電子証明書に対するアクセス権限確認では異なるIDとパスワードを用いることにして従来より厳重なアクセス管理を行なうこともできる。必要に応じて、アクセス管理方式を選択することによって、より柔軟なシステムの運用管理が実現される。
【0055】
続いてステップS13で対象証明書の秘密鍵が取り出され、その対象証明書についてのアクセスのログがとられ、ステップS14で秘密鍵を用いて署名対象電子データについての電子署名が行なわれる。すなわちハッシュ関数を用いてメッセージダイジェストが作成され、メッセージダイジェストが秘密鍵によって暗号化される。ここで秘密鍵としては、図5の証明書鍵保管テーブルに格納されている秘密鍵が使用される。
【0056】
ステップS15で公開鍵を用いて署名対象電子データと電子署名が暗号化され、ステップS16で原本処理が行われる。この原本保存処理では、図9で説明した原本管理レベルに従って、原本保存サーバ17に電子データと電子署名が保存され、ステップS17で相手先のサーバ/クライアント16に対して電子データとその電子署名が送信されて、送付ログがとられ、処理を終了する。
【0057】
PKI鍵管理サーバ10による電子署名処理における出力としては、基本的な出力として署名対象電子データと電子署名、アクセスログとデータ送付のログが出力され、更に原本保存サーバ17に対して署名対象電子データと電子署名が出力され、相手先サーバ/クライアント16に対しては、電子データと電子署名が送付されることになる。
【0058】
図11は電子署名処理のフローチャート(その2)であり、すでに電子署名がなされている電子データが、例えばアプリケーション側で用いられている場合に、その電子署名に用いられた証明書の有効期限が近づいた時点でアプリケーション側から例えば証明期間の延長された電子証明書を用いた再署名の要求があった時に行なわれる処理のフローチャートである。
【0059】
このような処理は、図2において図示しないアプリケーションサーバなどからの要求によって、PKI鍵管理サーバ10によって自動的に行なわれるものである。この要求において、アプリケーション側は署名要求者として、PKI鍵管理サーバ10自体のサーバ名と、このサーバの管理者、例えば図7で説明したシステム管理者のIDとパスワードを用いて電子署名の要求を行なうものとする。ここでサーバ名の入力は、例えば複数のPKI鍵管理サーバが用いられ、サーバ管理者が同一でも、同一アクセス可能者に対応する電子証明書が別のPKI鍵管理サーバによって管理されている場合に必要となる。
【0060】
図11のステップS21で、サーバ管理者名を用いて認証サーバ11のデータベース15に登録されているアクセス可能者のデータが検索され、サーバ管理者のアクセス権限が確認されるとアクセスログがとられ、図10で説明したステップS12以降の処理が行なわれる。
【0061】
但し図6で説明した証明書鍵アクセス管理テーブル内のアクセス可能者のID、パスワードとしてサーバ管理者のID、パスワードが設定されており、これによって対象証明書に対するアクセス権限の確認が行なわれる。
【0062】
図12は、図4の鍵保管処理部21による電子証明書の登録、削除、および更新処理のフローチャートである。本実施形態では、これらの処理は図6で説明した証明書IDと証明書名称とに対応する証明書鍵管理者によって、またはこの管理者と証明書アクセス可能者(証明書所有者、すなわち認証局への証明書発行依頼者)との合意に基づいて実行されるものとするが、ここでは証明書鍵管理者側の処理起動に対応して、証明書鍵管理者と証明書所有者との合意に基づいて行なわれるものとして処理を説明する。証明書所有者側の処理起動に対応しても、同様の処理が行なわれる。
【0063】
図12において、証明書鍵管理者によって処理の対象となる証明書の名称と、登録や更新の場合には、X.509の規定に従って証明書の所有者が記載されている証明書とが入力され、ステップS25で図6の証明書IDに対応する管理者IDとアクセス可能者のIDとによって証明書鍵管理者と所有者とが特定され、証明書鍵管理者に対しては登録、更新、削除の3つのボタンが表示される。
【0064】
これに対して証明書鍵管理者は、3つのボタンのうち、いずれかのボタンを選び、指示の入力を行なうと、ステップS26で承認申請中の状態となり、承認の決裁の依頼が合意すべき相手、ここでは証明書所有者に対して発行され、証明書所有者に対する承認決裁依頼が出力される。
【0065】
合意者、ここでは証明書所有者が承認すると、ステップS27で登録、更新、削除可能フラグが立てられ、承認の状態となって登録、更新、削除のボタンが有効になり、証明書鍵管理者に対してこれらのボタンの有効表示が出力され、証明書鍵管理者がこれらの3つのボタンのうちのいずれかを選択して、例えばそのボタンを押し下げることによって、ステップS28で証明書の登録、更新、または削除処理が行なわれ、処理を終了する。
【0066】
証明書の登録処理では、図5の証明書鍵保管テーブルと図6の証明書鍵アクセス管理テーブルとのそれぞれに必要な項目が追加され、更新処理では図5の証明書鍵保管テーブルの本体と秘密鍵の項目が更新され、削除処理においては本体の項目に無効の書込みが行なわれる。すなわち削除処理においても、記録の保持などのために、関連する全ての項目を消去するような処理は実行されない。
【0067】
以上において本発明の電子データ署名装置についてその詳細を説明したが、この装置は当然一般的なコンピュータシステムとして構成することが可能である。図13はそのようなコンピュータシステム、すなわちハードウエア環境の構成ブロック図である。
【0068】
図13においてコンピュータシステムは中央処理装置(CPU)30、リードオンリメモリ(ROM)31、ランダムアクセスメモリ(RAM)32、通信インタフェース33、記憶装置34、入出力装置35、可搬型記憶媒体の読み取り装置36、およびこれらの全てが接続されたバス37によって構成されている。
【0069】
記憶装置34としてはハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置34、またはROM31に図3,図10〜12などのフローチャートに示されたプログラムや、本発明の特許請求の範囲の請求項5のプログラムなどが格納され、そのようなプログラムがCPU30によって実行されることにより、本実施形態における複数種類の電子証明書の一括管理、署名要求者のアクセス権限確認後の電子署名などが可能となる。
【0070】
このようなプログラムは、プログラム提供者38側から、ネットワーク39、および通信インタフェース33を介して、例えば記憶装置34に格納されることも、また市販され、流通している可搬型記憶媒体40に格納され、読み取り装置36にセットされて、CPU30によって実行されることも可能である。可搬型記憶媒体40としてはCD−ROM、フレキシブルディスク、光ディスク、光磁気ディスク、DVDなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読み取り装置36によって読み取られることにより、本実施形態における電子データに対する電子署名が可能となる。
【0071】
以上において本発明の実施形態について詳細に説明したが、このような実施形態において、様々な分野における電子データへの署名を実行することができる。まず第1に、官庁におけるPKIの証明書管理と、電子文書に対する電子署名、および関係部署への送付と、原本の保存とを実行することができる。
【0072】
第2に、民間企業における電子商取引(EC)でのPKI証明書管理と、ECデータに対する電子署名、関係部門へのデータの送付、および原本保存を行なうことができる。
【0073】
第3に、医療機関における電子入札での入札企業のセキュリティポリシーに基づいたアクセス制御を実行することができる。
第4に、電子カルテにおけるPKI証明書の管理と、電子カルテに対する電子署名、関係部門への送付、および、原本保存を行なうことができる。
【0074】
【発明の効果】
以上詳細に説明したように、本発明によれば、複数の電子証明書を一括管理することにより、公開鍵、秘密鍵を含む電子証明書の安全性を飛躍的に向上させることが可能となる。サーバの設置されたサーバルームへの出入管理を厳重にすることにより、証明書の盗難を検出しやすくなり、媒体にコピーして持ち出そうとしてもアクセス制限をかけることができる。更に、遠隔地に証明書のバックアップをおくことなど、一括管理がしやすくなり、地震や火災に対する対策もとりやすくなり、電子署名方式を用いた電子データの信頼性向上に寄与するところが大きい。
【図面の簡単な説明】
【図1】本発明の電子データ署名装置の原理構成ブロック図である。
【図2】電子データ署名装置に相当するPKI鍵管理サーバを含む電子署名方式の構成ブロック図である。
【図3】本実施形態における電子署名処理の基本フローチャートである。
【図4】PKI鍵管理サーバにおけるソフトウエア構成を示す図である。
【図5】証明書鍵保管テーブルの格納内容の例を示す図である。
【図6】証明書鍵アクセス管理テーブルの格納内容の例を示す図である。
【図7】システムおよびログ管理者テーブルの格納内容の例を示す図である。
【図8】ログレベル管理テーブルの格納内容の例を示す図である。
【図9】原本管理テーブルの格納内容の例を示す図である。
【図10】電子署名処理の詳細フローチャート(その1)である。
【図11】電子署名処理の詳細フローチャート(その2)である。
【図12】電子証明書の登録、削除、および更新処理のフローチャートである。
【図13】本実施形態におけるプログラムのコンピュータへのローディングを説明する図である。
【図14】電子署名方式の従来例を説明する図である。
【符号の説明】
1 電子データ署名装置
2 電子証明書記憶手段
3 アクセス制御手段
4 署名処理手段
10 PKI鍵管理サーバ
11 認証サーバ
12 ECクライアント
13 ECシステム
14 クライアント
15 データベース
16 相手先サーバ/クライアント
17 原本保存サーバ
20 証明書鍵保管データベース
21 鍵保管処理部
22 アクセス制御処理部
23 証明書選択処理部
24 電子署名処理部
25 送受信・原本保存処理部
26 アクセスログ処理部
27 署名検証処理部
30 中央処理装置(CPU)
31 リードオンリメモリ(ROM)
32 ランダムアクセスメモリ(RAM)
33 通信インタフェース
34 記憶装置
35 入出力装置
36 読み取り装置
37 パス
38 プログラム提供者
39 ネットワーク
40 可搬型記憶媒体
51 パソコン
52 ICカード
53 サーバ
54 インターネット
55 相手先サーバ/クライアント
[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an electronic signature system for electronic data, and more particularly, based on a public key infrastructure (PKI), for example, an electronic data signature apparatus for performing electronic signature on electronic data to ensure communication reliability, and its The present invention relates to a program used in an apparatus.
[0002]
[Prior art]
A public key infrastructure PKI (Public Key Infrastructure) that enhances data reliability by encrypting data and digitally signing communication data using a public key system is used.
[0003]
FIG. 14 is an explanatory diagram of a conventional example of an electronic signature method using such a public key. Conventionally, an electronic certificate (digital certificate) as a set including a public key and a private key issued by a certificate authority is stored in the personal computer 51, the IC card 52, or the server 53, and is used for electronic data. The electronic signature is sent to the other server / client 55 via the Internet 54, for example.
[0004]
That is, when the electronic certificate as a set including the public key and the private key issued from the recognition station is stored in the personal computer 51 or the IC card 52, the electronic certificate including the private key is stored by those users. There was only personal management. Even when stored in the server 53, the management of a plurality of electronic certificates is generally not performed uniformly.
[0005]
Therefore, when managing a plurality of electronic certificates, whether to store a plurality of electronic certificates in the personal computer 51 for personal management, whether to have a plurality of IC cards 52, or to be managed by a plurality of servers I had to take such a method.
[0006]
There are the following documents as conventional techniques related to such an electronic signature.
[0007]
[Patent Document 1]
JP 2000-224164 A
"Device that supports multiple cryptographic algorithms simultaneously"
[Patent Document 2]
JP 2002-171289 A
"Policy Server, Proxy and Router"
[Patent Document 3]
JP 2002-207427 A
“Public Key Certificate Issuing System, Public Key Certificate Issuing Method, Information Processing Apparatus, Information Recording Medium, and Program Storage Medium”
[Non-Patent Document 1]
http: // job8. nikki. ne. jp / Companyarticle / 79773 /, VeriSign Japan “Roaming Service” (2002.7 NEWS RELEASE)
Japanese Patent Application Laid-Open No. 2004-151867 has the disadvantage that only one encryption algorithm can be supported at a time. 509 techniques are disclosed that allow certificates to support multiple cryptographic algorithms simultaneously.
[0008]
Japanese Patent Application Laid-Open No. 2004-151867 is a technology that enables all devices to be controlled by the same policy even when the network operation method for realizing the same function in a policy-controlled network is different for each vendor or for each device. Is disclosed.
[0009]
Patent Document 3 discloses a technology that enables mutual verification of a public key certificate between devices that can process different signature algorithms in order to ensure security in data communication via a network, for example. ing.
[0010]
In Non-Patent Document 1, as system development / software news, an electronic certificate and a private key necessary for its use are stored on the server side, and an electronic certificate can be obtained without purchasing special hardware from any terminal. The provision of digital trust services that can be used has been reported.
[0011]
[Problems to be solved by the invention]
However, in such a conventional technique, when a set of a public key, a private key, and an electronic certificate is individually managed, a management security problem and a plurality of electronic certificates are managed. Problems such as complexity and increased costs for management occur.
[0012]
Even when such a set is managed collectively, setting IDs and passwords for a plurality of sets of PKI certificates, private keys, and public keys will be cumbersome, and the actual signature operation will be difficult. There was a problem of becoming complicated.
[0013]
In addition, new re-signing of electronic data is required before the certificate expires, but if there is a large amount of electronic data to be re-signed, it is difficult to process the signature request personally. There was also a problem.
[0014]
In view of the above-described problems, an object of the present invention is to collectively manage a plurality of sets of electronic certificates, private keys, and public keys, and to sign and encrypt electronic data. In order to improve the security and re-signature of electronic data before the certificate expires, for example, by enabling an automatic signature request from the application side, a large number of electronic signatures This is to simplify the process.
[0015]
[Means for Solving the Problems]
FIG. 1 is a block diagram showing the principle configuration of an electronic data signature apparatus according to the present invention. In FIG. 1, an electronic data signature apparatus 1 includes an electronic certificate storage unit 2, an access control unit 3, and a signature processing unit 4.
[0016]
The electronic certificate storage unit 2 stores a plurality of types of electronic certificates based on a public key, for example, an electronic certificate including a public key, a private key, and other certificate parts, and an administrator and an accessible person for each certificate. Is stored together with data indicating.
[0017]
In response to the signature request including the signature requester data input together with the electronic data and the data designating the electronic certificate to be used for the signature, the access control means 3 performs the electronic certificate storage means 2 The signature processing means 4 uses the designated electronic certificate after the confirmation to confirm that it is a legitimate accessible person of the electronic certificate stored in the electronic data. The electronic signature is executed for the.
[0018]
In the embodiment of the invention, in the electronic data signing device, the registration, update, and registration of the certificate in the electronic certificate storage unit 2 based on the agreement between the key manager and the accessible person for each certificate Certificate registration means for performing deletion can also be provided.
[0019]
In the embodiment, corresponding to the electronic data signature device, the electronic data signature device is based on the same or different data indicating the accessible person stored in the electronic certificate storage unit 2. An authentication device that authenticates whether or not access is possible can also be provided.
[0020]
In the embodiment, the administrator of the electronic data signature apparatus is designated as the above-mentioned signature requester, and the access control means 3 confirms a valid accessible person in response to the signature request given from the application side. This makes it possible to automatically process a large number of signature requests given from the application side.
[0021]
Further, as a program for an electronic signature device of the present invention, an electronic signature request including data of a signature requester input together with electronic data and data designating an electronic certificate to be used is received, and a plurality of types of public key infrastructure are received. The signature requester is a legitimate accessible person by referring to the stored contents of the electronic certificate storage device that stores the electronic certificate together with data indicating the administrator and the accessible person for each of the plurality of certificates. And a program for causing the computer to execute an electronic signature for the input electronic data using the designated electronic certificate after the confirmation is made, and the computer storing this program A readable portable storage medium is used.
[0022]
As described above, according to the present invention, multiple types of electronic certificates as a set including a public key and a private key are collectively managed together with data indicating an administrator and an accessible person for each certificate. The
[0023]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 2 is a configuration block diagram of an electronic data signature method in which the PKI key management server 10 as an embodiment of the electronic data signature apparatus of the present invention is used. In the figure, a PKI key management server 10 plays a fundamentally important role in a signature operation for electronic data together with an authentication server 11 that determines whether or not access to the server 10 is possible.
[0024]
For example, a signature application from an EC (electronic commerce) client 12 is made to the EC system 13, and a signature request as a result of settlement is sent to the PKI key management server 10. Alternatively, a signature request from the client 14 is sent to the PKI key management server 10.
[0025]
The PKI key management server 10 inquires of the authentication server 11 whether the client as the request source has the authority to access the server 10, that is, generally the authority to request the electronic signature, and the authentication server 11 This is determined by the contents of the database 15. The database 15 stores IDs and passwords of persons who can access the PKI key management server 10, and the authentication server 11 has authority to access the PKI key management server 10 to clients who have requested a signature using these contents. Check if there is any.
[0026]
If there is access authority, the PKI key management server 10 is designated from the client side among a plurality of electronic certificates (a set including a public key and a private key) stored in a certificate key storage database to be described later. The client is further confirmed whether or not the client has the authority to access the certificate. If the authority is granted, the electronic data is digitally signed and encrypted, and the destination server / client 16 is connected to the backbone LAN. The data is sent via the Internet or intranet (WAN) and further via the Internet, LG (local government, local government) WAN, or the like, and the original data storage server 17 sends the original data to the original storage server 17 for storage.
[0027]
In addition, between the PKI key management server 10 and the authentication server 11, the original storage server 17, and each client, data transmission is secured by using encrypted transmission or a closed network such as a backbone LAN, an intranet, or a WAN. I will secure it.
[0028]
FIG. 3 is a basic processing flowchart of the electronic data signature method according to this embodiment. When the processing is started in the figure, first, a confirmation notice of accessibility from the authentication server 11 is received in step S1, and the access authority of the signing requester to the target electronic certificate is confirmed in step S2. In step S3, the target certificate is taken out and an electronic signature is applied to the electronic data. In step S4, the original is stored in the original storage server 17. In step S5, the electronic data with the electronic signature is transferred to the partner server / client 16. To finish the process.
[0029]
FIG. 4 is an explanatory diagram of a software configuration in the PKI key management server 10. In FIG. 1, the PKI key management server 10 is provided with a certificate key storage database 20, and this database 20 includes basic certificate key storage tables, certificate key access management tables, and system management tables described later. Three types of tables are stored.
[0030]
In FIG. 4, a key storage processing unit 21 registers, deletes, and updates a certificate issued from a certificate authority such as G (Government) PKI. The processing is performed based on an instruction by the administrator for each certificate or an agreement (electronic approval, that is, an agreement by workflow) between the certificate administrator and an accessible person (owner) for the certificate. The key storage processing unit 21 sets, changes, and deletes the accessible person ID and password for each certificate.
[0031]
The access control processing unit 22 is stored in the certificate key access management table and the confirmation result by the data of the person who can access the PKI key management server 10 stored in the database 15 of the authentication server 11 described in FIG. The access to the electronic certificate is controlled using data indicating the certificate accessible person. If it is determined that the signature requester is registered as both accessible persons, the next certificate selection processing unit 23 is activated.
[0032]
The certificate selection processing unit 23 selects an electronic certificate that is approved for access by the access control processing unit 22 and designated by the signature requester from the certificate key storage table, and the electronic signature processing unit 24 selects the selected electronic certificate. The electronic signature is executed on the input electronic data using the certificate.
[0033]
The transmission / reception / original storage processing unit 25 executes transmission of electronic data with an electronic signature to the partner server / client 16 in FIG. 2 and original storage processing to the original storage server 17. In the original storage process, the original storage server 17 executes storage corresponding to a set storage level such as encrypted storage + signature storage, plain text storage + signature storage, plain text storage, no storage, etc. as the storage level. The original storage server 17 can refer to the stored electronic data.
[0034]
In other words, the original storage server 17 guarantees the integrity, confidentiality, and readability of the original document, thereby preventing loss of signed electronic data, proof of signature time, and long-term data reference. Become.
[0035]
The access log processing unit 26 logs logs for access to the PKI key management server 10, access to certificates stored in the certificate key storage database 20, and electronic data transmission to the destination server / client 16. Log data is collected and stored according to the set level, such as a detailed log, main data log, and no log. This log data is also encrypted as necessary.
[0036]
The signature verification processing unit 27 verifies the electronic data with the electronic signature. The signature verification processing unit 27 determines whether the electronic data has been tampered with, a hash value for the electronic data, and a value obtained by decrypting the electronic signature with the public key. It is verified by comparison. By this verification, it can be proved that the electronic data that has been digitally signed by the PKI key management server 10 has not been tampered with.
[0037]
The electronic certificate storage means in claims 1 and 3 of the claims is the certificate key storage table in the certificate key storage database 20 of FIG. 4, the access control means is in the access control processing section 22, and the signature processing. The means corresponds to the electronic signature processing unit 24, and the certificate registration means corresponds to the key storage processing unit 21.
[0038]
FIG. 5 is an example of the contents stored in the certificate key storage table stored in the certificate key storage database 20 of FIG. In the same figure, the certificate ID and the certificate name are unique corresponding to the certificate authority as a third party organization, and for the certificate ID = 1, the certificate name is LGPKI, for example. For ID = 2, the certificate name is GPKI, and for ID = 3, the certificate name is, for example, (authentication) service company A.
[0039]
The individual ID, the main body, and the private key correspond to individual certificates, and the main body and the private key including the public keys corresponding to the individual IDs 001 and 002 are stored as certificates issued by LGPKI. Has been.
[0040]
In addition, as a certificate issued by GPKI, a main body and a secret key for each of certificates having individual IDs 011 and 012 are stored.
Here, for example, for a certificate issued by GPKI with an individual ID of 011, it is clear that the certificate name is GPKI, and the individual ID can be set to 001.
[0041]
In this case, for each certificate having the same certificate ID and certificate name, the individual ID, the main body, and the private key are stored together in the table. For example, it is naturally possible to exchange the second and third rows in the table.
[0042]
Here, the set of PKI certificate, public key, and private key is set by the certificate key manager according to ITU (International Telecommunication Union) standard protocol X. Stored in accordance with the format 509.
[0043]
As will be described later, only the certificate key administrator is allowed to register, update, or delete the electronic certificate including the private key in the certificate key storage table, or the administrator and the owner of the electronic certificate If it is allowed only under the terms of the agreement, it is possible to prevent tampering or deletion of the private key due to impersonation of the certificate holder, registration of an illegal private key, and the like.
[0044]
FIG. 6 shows an example of the contents stored in the certificate key access management table in the certificate key storage database 20. In this embodiment, for example, a key manager is provided corresponding to each certificate ID, that is, a certificate name. For example, the ID of the certificate key manager for certificate ID = 1 is 1234, and the corresponding password Is also stored.
[0045]
The ID and password of the person who can access the electronic certificate having the individual ID stored in the certificate key storage table of FIG. 5 are stored together for each certificate ID here.
[0046]
For example, among certificates issued by LGPKI having a certificate ID of 1, a certificate having an individual ID of 001 is accessible to a certificate having an accessible person ID of 4567 and 002. It is indicated that the person's ID is 3456, and an accessible person having 3456 as an ID simultaneously accesses an electronic certificate having a certificate ID of 2, that is, 011 as an individual ID issued by GPKI. It has been shown to be possible.
[0047]
7 to 9 are explanatory diagrams of three tables constituting the system management table in the certificate key storage database 20. FIG. 7 is a system and log manager table. The ID and password of a system manager who manages the PKI key management server 10 itself of FIG. 2 as a system, and log management for managing log processing by the access log processing unit 26 of FIG. The person's ID and password are stored. In this embodiment, in order to distribute the risk, a system administrator (server administrator) and a log administrator are provided separately. Also, by limiting the number of server managers and certificate key managers, security awareness can be improved through education and training.
[0048]
FIG. 8 shows an example of the contents stored in the log level management table. In the figure, log levels are set corresponding to the types of access. First, the main data log for the server access log to the PKI key management server 10 itself authenticated by the authentication server 11, the detailed log for access to the electronic certificate itself, and the data transmission to the destination server / client No log is set.
[0049]
By acquiring logs for access and data transmission in this way, records are saved even if fraud such as data tampering, wiretapping, and impersonation has been made, and whether or not fraud has occurred and its contents, i.e. who, when, what It is possible to identify whether fraud has been performed.
[0050]
FIG. 9 is an example of the contents stored in the original management table for setting the storage level in the original storage server 17 in FIG. Here, for individual processing, for example, electronic data signature processing individually requested from the EC client 12 or client 14 in FIG. 2, the level of encryption storage + signature storage is automatic processing, that is, for example, as described later. Save the plaintext + signature in response to the automatic processing that performs the electronic signature processing again in response to a request from the application side, for example, because the electronic signature expires in the electronic data that has already been signed. The save level is set.
[0051]
FIG. 10 is a detailed flowchart (part 1) of the electronic signature processing. In this figure, processing is performed for the electronic data to be signed, the certificate name to be used and its individual ID, the signature requester (including ID and password), the destination of the data, and the input of the original management level as necessary. Is started. The original management level is given as input data when a level different from that shown in FIG. 9 is set for each piece of input electronic data.
[0052]
First, in step S11, whether or not the signature requester has access authority to the PKI key management server 10 is confirmed using the contents of the database 15 on the authentication server 11 side, an access log is taken, and specified in step S12. It is confirmed whether or not the signature requester has access authority corresponding to the received certificate, and the target certificate is selected. This access authority is confirmed using the contents of the certificate key access management table of FIG.
[0053]
As described above, the steps of confirming the access authority to the PKI key management server 10 itself and confirming the access authority to the certificate are sequentially executed, and as a result, two confirmation conditions are ANDed, and the electronic signature is obtained. Will be executed.
[0054]
As for the ID and password used in the confirmation of these two access authorities, it is possible to use the ID and password normally used by the signature requester as they are in common for the two confirmations. In the access authority confirmation, different IDs and passwords can be used so that stricter access management than before can be performed. By selecting an access management method as required, more flexible system operation management is realized.
[0055]
Subsequently, in step S13, the private key of the target certificate is taken out, an access log for the target certificate is taken, and in step S14, an electronic signature is performed on the electronic data to be signed using the private key. That is, a message digest is created using a hash function, and the message digest is encrypted with the secret key. Here, a secret key stored in the certificate key storage table of FIG. 5 is used as the secret key.
[0056]
In step S15, the signature target electronic data and the electronic signature are encrypted using the public key, and the original process is performed in step S16. In this original storage process, the electronic data and electronic signature are stored in the original storage server 17 in accordance with the original management level described with reference to FIG. 9, and the electronic data and electronic signature are sent to the destination server / client 16 in step S17. The transmission log is taken and the processing is terminated.
[0057]
As an output in the electronic signature processing by the PKI key management server 10, a signature target electronic data and electronic signature, an access log and a data transmission log are output as basic outputs, and the signature target electronic data is further output to the original storage server 17. And the electronic signature and the electronic signature are sent to the destination server / client 16.
[0058]
FIG. 11 is a flowchart (part 2) of the electronic signature process. When electronic data that has already been digitally signed is used on the application side, for example, the expiration date of the certificate used for the digital signature is FIG. 10 is a flowchart of processing performed when there is a request for resignature using, for example, an electronic certificate with an extended certification period when approaching.
[0059]
Such processing is automatically performed by the PKI key management server 10 in response to a request from an application server (not shown in FIG. 2). In this request, the application side requests the electronic signature using the server name of the PKI key management server 10 itself and the ID and password of the server administrator, for example, the system administrator described in FIG. Shall be done. Here, the server name is input when, for example, a plurality of PKI key management servers are used, and even if the server administrators are the same, electronic certificates corresponding to the same accessible persons are managed by different PKI key management servers. Necessary.
[0060]
In step S21 in FIG. 11, data of accessible persons registered in the database 15 of the authentication server 11 is searched using the server administrator name, and an access log is taken when the access authority of the server administrator is confirmed. Then, the processing after step S12 described in FIG. 10 is performed.
[0061]
However, the ID and password of the server administrator are set as the ID and password of the accessible person in the certificate key access management table described with reference to FIG. 6, thereby confirming the access authority for the target certificate.
[0062]
FIG. 12 is a flowchart of electronic certificate registration, deletion, and update processing by the key storage processing unit 21 of FIG. In this embodiment, these processes are performed by the certificate key manager corresponding to the certificate ID and certificate name described in FIG. 6 or by this manager and the certificate accessible person (certificate owner, ie, authentication). This is executed based on the agreement with the certificate issuance requester), but here the certificate key manager and the certificate owner The processing will be described as being performed based on the agreement. The same processing is performed even when corresponding to the processing activation on the certificate owner side.
[0063]
In FIG. 12, the name of the certificate to be processed by the certificate key manager, and X. A certificate in which the certificate owner is written in accordance with the provisions of 509 is input, and in step S25, the certificate key administrator and the accessible person ID are identified by the administrator ID corresponding to the certificate ID of FIG. The owner is specified, and three buttons of registration, update, and deletion are displayed for the certificate key manager.
[0064]
On the other hand, when the certificate key manager selects one of the three buttons and inputs an instruction, the approval key is in the application state in step S26 and the approval decision request should be agreed. It is issued to the other party, here the certificate owner, and an approval / approval request to the certificate owner is output.
[0065]
When the consensus, here the certificate owner, approves, a registration, update, and deletion enable flag is set in step S27, and the registration, update, and deletion buttons become valid, and the certificate key manager A valid display of these buttons is output, and the certificate key manager selects any one of these three buttons and, for example, depresses the button to register the certificate in step S28. An update or delete process is performed, and the process ends.
[0066]
In the certificate registration process, necessary items are added to each of the certificate key storage table in FIG. 5 and the certificate key access management table in FIG. 6, and in the update process, the main body of the certificate key storage table in FIG. The item of the secret key is updated, and invalid writing is performed on the item of the main body in the deletion process. That is, even in the deletion process, a process that deletes all related items is not executed in order to keep records.
[0067]
Although the details of the electronic data signature apparatus of the present invention have been described above, this apparatus can naturally be configured as a general computer system. FIG. 13 is a block diagram showing the configuration of such a computer system, that is, a hardware environment.
[0068]
In FIG. 13, the computer system includes a central processing unit (CPU) 30, a read only memory (ROM) 31, a random access memory (RAM) 32, a communication interface 33, a storage device 34, an input / output device 35, and a portable storage medium reading device. 36, and a bus 37 to which all of these are connected.
[0069]
As the storage device 34, various types of storage devices such as a hard disk and a magnetic disk can be used. Such a storage device 34 or a program shown in the flowchart of FIG. The program of claim 5 of the claims of the present invention is stored, and such a program is executed by the CPU 30 to collectively manage a plurality of types of electronic certificates and to access the signature requester in this embodiment. Electronic signatures after authority confirmation are possible.
[0070]
Such a program is stored, for example, in the storage device 34 from the program provider 38 via the network 39 and the communication interface 33, or in a portable storage medium 40 that is commercially available and distributed. It can also be set in the reading device 36 and executed by the CPU 30. As the portable storage medium 40, various types of storage media such as CD-ROM, flexible disk, optical disk, magneto-optical disk, and DVD can be used, and the program stored in such a storage medium is read by the reading device 36. By being read, the electronic signature for the electronic data in the present embodiment is possible.
[0071]
Although the embodiments of the present invention have been described in detail above, in such embodiments, it is possible to execute signatures on electronic data in various fields. First, it is possible to execute PKI certificate management in the government office, electronic signatures for electronic documents, sending to related departments, and saving of originals.
[0072]
Secondly, PKI certificate management in electronic commerce (EC) in a private company, electronic signature on EC data, sending of data to related departments, and original storage can be performed.
[0073]
Thirdly, it is possible to execute access control based on the security policy of the bid company in the electronic bidding in the medical institution.
Fourth, management of PKI certificates in electronic medical records, electronic signatures on electronic medical records, sending to related departments, and original storage can be performed.
[0074]
【The invention's effect】
As described above in detail, according to the present invention, it is possible to dramatically improve the security of an electronic certificate including a public key and a private key by collectively managing a plurality of electronic certificates. . Strict entry / exit management to the server room where the server is installed makes it easier to detect certificate theft and restricts access even if it is copied to a medium and taken out. In addition, it is easy to perform batch management such as backing up certificates in remote locations, and it is easy to take measures against earthquakes and fires, which greatly contributes to improving the reliability of electronic data using the electronic signature method.
[Brief description of the drawings]
FIG. 1 is a block diagram showing the principle configuration of an electronic data signature apparatus according to the present invention.
FIG. 2 is a configuration block diagram of an electronic signature method including a PKI key management server corresponding to an electronic data signature device.
FIG. 3 is a basic flowchart of electronic signature processing in the present embodiment.
FIG. 4 is a diagram showing a software configuration in a PKI key management server.
FIG. 5 is a diagram showing an example of the contents stored in a certificate key storage table.
FIG. 6 is a diagram showing an example of the contents stored in a certificate key access management table.
FIG. 7 is a diagram illustrating an example of stored contents of a system and log manager table;
FIG. 8 is a diagram showing an example of the contents stored in a log level management table.
FIG. 9 is a diagram illustrating an example of the contents stored in an original management table.
FIG. 10 is a detailed flowchart (part 1) of the electronic signature processing;
FIG. 11 is a detailed flowchart (part 2) of the electronic signature processing;
FIG. 12 is a flowchart of electronic certificate registration, deletion, and update processing.
FIG. 13 is a diagram illustrating loading of a program into a computer according to the present embodiment.
FIG. 14 is a diagram for explaining a conventional example of an electronic signature method.
[Explanation of symbols]
1 Electronic data signature device
2 Electronic certificate storage means
3 Access control means
4 Signature processing means
10 PKI key management server
11 Authentication server
12 EC client
13 EC system
14 clients
15 Database
16 Destination server / client
17 Original storage server
20 Certificate key storage database
21 Key storage processing part
22 Access control processor
23 Certificate selection processing section
24 Electronic Signature Processing Department
25 Transmission / Reception / Original Store Processing Unit
26 Access log processor
27 Signature verification processor
30 Central processing unit (CPU)
31 Read-only memory (ROM)
32 Random access memory (RAM)
33 Communication interface
34 Storage device
35 I / O devices
36 Reader
37 passes
38 Program provider
39 Network
40 Portable storage media
51 PC
52 IC card
53 servers
54 Internet
55 Destination server / client

Claims (6)

電子データに対して電子署名を行う装置において、
公開鍵基盤の複数の電子証明書を、該複数の各証明書毎の管理者とアクセス可能者とを示すデータと共に記憶する電子証明書記憶手段と、
電子データと共に入力される署名要求者のデータと使用すべき電子証明書を指定するデータを含む電子署名要求に対応して、該署名要求者が該電子証明書記憶手段に記憶されている電子証明書の正当なアクセス可能者であることを確認するアクセス制御手段と、
該確認後に、指定された電子証明書を用いて、入力された電子データに対する電子署名を実行する署名処理手段とを備えることを特徴とする電子データ署名装置。
In a device that digitally signs electronic data,
Electronic certificate storage means for storing a plurality of public key-based electronic certificates together with data indicating an administrator and an accessible person for each of the plurality of certificates;
An electronic certificate stored in the electronic certificate storage means by the signature requester in response to an electronic signature request including data of the signature requester input together with the electronic data and data specifying an electronic certificate to be used Access control means for confirming that the document is legitimately accessible,
An electronic data signature apparatus comprising: signature processing means for executing an electronic signature on the input electronic data using the designated electronic certificate after the confirmation.
前記電子データ署名装置に対応して、前記電子証明書記憶手段に記憶されているアクセス可能者を示すデータと同一のデータ、または異なるデータに基づいて、該電子データ署名装置に対するアクセスの可否を認証する認証装置を更に備えることを特徴とする請求項1記載の電子データ署名装置。Corresponding to the electronic data signature apparatus, the access to the electronic data signature apparatus is authenticated based on the same or different data indicating the accessible person stored in the electronic certificate storage means. The electronic data signature apparatus according to claim 1, further comprising an authentication apparatus that performs the authentication. 前記電子データ署名装置において、
前記証明書毎の管理者とアクセス可能者との両方の合意に基づいて、前記電子証明書記憶手段への証明書の登録、更新、および削除を行なう証明書登録手段を更に備えることを特徴とする請求項1記載の電子データ署名装置。
In the electronic data signature device,
And further comprising certificate registration means for registering, updating, and deleting a certificate in the electronic certificate storage means based on the agreement of both the administrator and the accessible person for each certificate. The electronic data signing apparatus according to claim 1.
前記電子データ署名装置において、
前記署名要求者として該電子データ署名装置の管理者が指定され、外部のアプリケーション側から与えられる署名要求に対応して、前記アクセス制御手段が、前記正当なアクセス可能者の確認を行なうことを特徴とする請求項1記載の電子データ署名装置。
In the electronic data signature device,
An administrator of the electronic data signing apparatus is designated as the signature requester, and the access control means confirms the legitimate accessible person in response to a signature request given from an external application side. The electronic data signature apparatus according to claim 1.
電子データに対して電子署名を行なう計算機によって使用されるプログラムにおいて、
電子データと共に入力される署名要求者のデータと、使用すべき電子証明書を指定するデータとを含む電子署名要求を受け取り、公開鍵基盤の複数種類の電子証明書を、該複数の各証明書毎の管理者とアクセス可能者とを示すデータと共に記憶する電子証明書記憶装置の記憶内容を参照し、該署名要求者が正当なアクセス可能者であることを確認する手順と、
該確認後に、指定された電子証明書を用いて、入力された電子データに対する電子署名を実行する手順とを計算機に実行させるための電子データ署名装置用プログラム。
In a program used by a computer that performs an electronic signature on electronic data,
An electronic signature request including data of a signature requester input together with the electronic data and data specifying an electronic certificate to be used is received, and a plurality of types of electronic certificates based on a public key are assigned to each of the plurality of certificates. A procedure for confirming that the signature requester is a legitimate accessible person by referring to the stored contents of the electronic certificate storage device stored together with the data indicating each manager and accessible person;
A program for an electronic data signature device for causing a computer to execute a procedure for executing an electronic signature on input electronic data using a designated electronic certificate after the confirmation.
電子データに対して電子署名を行う計算機によって使用される記憶媒体において、
電子データと共に入力される署名要求者のデータと、使用すべき電子証明書を指定するデータとを含む電子署名要求を受け取り、公開鍵基盤の複数種類の電子証明書を、該複数の各証明書毎の管理者とアクセス可能者とを示すデータと共に記憶する電子証明書記憶装置の記憶内容を参照し、該署名要求者が正当なアクセス可能者であることを確認するステップと、
該確認後に、指定された電子証明書を用いて、入力された電子データに対する電子署名を実行するステップとを計算機に実行させるためのプログラムを格納した計算機読出し可能可搬型記憶媒体。
In a storage medium used by a computer that performs an electronic signature on electronic data,
An electronic signature request including data of a signature requester input together with the electronic data and data specifying an electronic certificate to be used is received, and a plurality of types of electronic certificates based on a public key are assigned to each of the plurality of certificates. Referring to the stored contents of the electronic certificate storage device stored together with the data indicating the administrator and the accessible person for each and confirming that the signature requester is a legitimate accessible person;
A computer-readable portable storage medium storing a program for causing a computer to execute a step of executing an electronic signature on input electronic data using a designated electronic certificate after the confirmation.
JP2003184655A 2003-06-27 2003-06-27 Electronic data signature device and program for signature device Pending JP2005020536A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2003184655A JP2005020536A (en) 2003-06-27 2003-06-27 Electronic data signature device and program for signature device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003184655A JP2005020536A (en) 2003-06-27 2003-06-27 Electronic data signature device and program for signature device

Publications (1)

Publication Number Publication Date
JP2005020536A true JP2005020536A (en) 2005-01-20

Family

ID=34184352

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003184655A Pending JP2005020536A (en) 2003-06-27 2003-06-27 Electronic data signature device and program for signature device

Country Status (1)

Country Link
JP (1) JP2005020536A (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008005090A (en) * 2006-06-21 2008-01-10 Nippon Telegr & Teleph Corp <Ntt> System for issuing and verifying certificates of several open keys, and method for issuing and verifying certificates of several open keys
JP2009212747A (en) * 2008-03-04 2009-09-17 Nec Corp Electronic signature system
JP2010200142A (en) * 2009-02-26 2010-09-09 Secom Co Ltd Electronic signature apparatus
JP2016051250A (en) * 2014-08-29 2016-04-11 日本電信電話株式会社 Function control system, method, setting information management apparatus, user terminal, and program
WO2021111824A1 (en) * 2019-12-03 2021-06-10 木戸 啓介 Electronic signature system and tamper-proof device

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1032570A (en) * 1996-07-15 1998-02-03 N T T Data Tsushin Kk Electronic signature system
JPH1188321A (en) * 1997-09-02 1999-03-30 Kiyadeitsukusu:Kk Digital signature generation server
JP2002247031A (en) * 2001-02-16 2002-08-30 Fujitsu Ltd Method for electronic signature

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1032570A (en) * 1996-07-15 1998-02-03 N T T Data Tsushin Kk Electronic signature system
JPH1188321A (en) * 1997-09-02 1999-03-30 Kiyadeitsukusu:Kk Digital signature generation server
JP2002247031A (en) * 2001-02-16 2002-08-30 Fujitsu Ltd Method for electronic signature

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008005090A (en) * 2006-06-21 2008-01-10 Nippon Telegr & Teleph Corp <Ntt> System for issuing and verifying certificates of several open keys, and method for issuing and verifying certificates of several open keys
JP2009212747A (en) * 2008-03-04 2009-09-17 Nec Corp Electronic signature system
JP2010200142A (en) * 2009-02-26 2010-09-09 Secom Co Ltd Electronic signature apparatus
JP2016051250A (en) * 2014-08-29 2016-04-11 日本電信電話株式会社 Function control system, method, setting information management apparatus, user terminal, and program
WO2021111824A1 (en) * 2019-12-03 2021-06-10 木戸 啓介 Electronic signature system and tamper-proof device
US11743053B2 (en) 2019-12-03 2023-08-29 Keisuke Kido Electronic signature system and tamper-resistant device

Similar Documents

Publication Publication Date Title
US11777726B2 (en) Methods and systems for recovering data using dynamic passwords
US11818265B2 (en) Methods and systems for creating and recovering accounts using dynamic passwords
US11153086B2 (en) Methods and systems for a digital trust architecture
US7028180B1 (en) System and method for usage of a role certificate in encryption and as a seal, digital stamp, and signature
US20180359092A1 (en) Method for managing a trusted identity
US7568114B1 (en) Secure transaction processor
WO2020062668A1 (en) Identity authentication method, identity authentication device, and computer readable medium
US8423762B2 (en) Common access card heterogeneous (CACHET) system and method
US7747852B2 (en) Chain of trust processing
US20020032665A1 (en) Methods and systems for authenticating business partners for secured electronic transactions
JP2007110377A (en) Network system
JP2002132730A (en) System and method for authentication or access management based on reliability and disclosure degree of personal information
JP2006525563A (en) User and web site authentication method and apparatus
JP2002033726A (en) System and method for effective and secure cancellation of signature certificate in public key infrastructure
US7013388B2 (en) Vault controller context manager and methods of operation for securely maintaining state information between successive browser connections in an electronic business system
KR102131206B1 (en) Method, service server and authentication server for providing corporate-related services, supporting the same
JP2002049311A (en) Method and system for automatically tracing certificate pedigree
US6795920B1 (en) Vault controller secure depositor for managing secure communication
US20060117179A1 (en) Method and system for delegating authority in an online collaborative environment
JPH10336172A (en) Managing method of public key for electronic authentication
JPH05298174A (en) Remote file access system
JPH1125045A (en) Access control method, its device, attribute certificate issuing device, and machine-readable recording medium
EP1164745A2 (en) System and method for usage of a role certificate in encryption, and as a seal, digital stamp, and a signature
JP2004140636A (en) System, server, and program for sign entrustment of electronic document
JP2005020536A (en) Electronic data signature device and program for signature device

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050816

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070927

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20071009

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071205

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20080318