JPWO2004100444A1 - 署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システム - Google Patents
署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システム Download PDFInfo
- Publication number
- JPWO2004100444A1 JPWO2004100444A1 JP2004571571A JP2004571571A JPWO2004100444A1 JP WO2004100444 A1 JPWO2004100444 A1 JP WO2004100444A1 JP 2004571571 A JP2004571571 A JP 2004571571A JP 2004571571 A JP2004571571 A JP 2004571571A JP WO2004100444 A1 JPWO2004100444 A1 JP WO2004100444A1
- Authority
- JP
- Japan
- Prior art keywords
- verification
- reliability
- data
- signature
- verification method
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
Abstract
発注側端末（１０）は、伝票作成部（１１）によって伝票データ（２１）を作成するとともに、検証方法指定部（１２）によって信頼性の検証方法を指定し、検証方法データ（２２）を作成する。署名作成部（１３）は、伝票データ（２１）および検証データ（２２）から署名（２３）を作成し、証明書取得部（１４）は証明書（２４）を取得する。これらの伝票データ（２１）、検証方法データ（２２）、署名（２３）、証明書（２４）を発注データ（２０）として送信し、受注方端末（３０）は、署名検証部３１によって署名（２３）を検証し、検証方法チェック部（３３）によって検証方法データ（２２）に示された検証方法の妥当性を確認して検証処理部（３４）によって証明書（２４）の信頼性を検証する。
Description
この発明は、デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法および署名信頼性検証プログラム、およびデジタル署名を用いたデータ通信システムに関し、特に、送受信されるデータの信頼性を検証可能な署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムに関する。
近年、インターネットなどのネットワークが普及するにつれて、ネットワーク通信におけるセキュリティ技術が重要となっている。特に、商取引などをネットワーク上で実現する電子商取引では、そのデータ内容の改竄をいかに防止するかが大きな課題である。
通信データの改竄を防止するため、従来、電子署名（デジタル署名）が用いられてきた。電子署名は公開鍵暗号を利用した技術であり、送信側は自らの秘密鍵を用いて署名を作成し、受信側は送信側の公開鍵を用いて署名を復号することで、署名の作成者が送信者に間違いがないことを確かめるものである。
この時、ＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）などの技術によって、データ内容のダイジェストを作成し、デジタル署名内部に含めることで、受信側はデータ内容が改竄されていないことを確認することが出来る。
ところで、このデジタル署名では、公開鍵が信頼できることが大前提となっている。すなわち、デジタル署名は公開鍵と秘密鍵が正しい対であることを示すに過ぎないので、悪意のある者が受信側に偽の公開鍵を渡すと共に、偽の秘密鍵によって作成したデータを送信したならば、受信側は偽の公開鍵でデータを復号できるがために、データ内容を信頼してしまうという問題が生じる。
そこで、デジタル署名を用いる場合には、認証局（ＣＡ）に公開鍵を登録し、ＣＡからの証明書を添付することで公開鍵の正当性を証明することが一般的である。
この認証局（ＣＡ）は、それぞれが信頼関係のネットワークを構築しているので、仮に送信側が登録したＣＡと受信側が利用しているＣＡとが異なる場合であっても、ＣＡ間のネットワークによって公開鍵の証明をおこなうことができる。
しかし、このＣＡ間のネットワークを用いて公開鍵の正当性を証明する処理は、受信者側に大きな負荷がかかる。そこで、たとえば特開２００２−１３９９９６号公報に公開された署名検証支援装置では、受信側に代わって送信側の公開鍵証明書の正当性を確認するようにしている。
しかしながら、このような従来のデジタル署名では、公開鍵の正当性を証明するために時間がかかるという問題点があった。近年、電子商取引の増加に伴い、処理速度の向上が求められているが、このような公開鍵の正当性証明する処理が処理遅延の原因となる。
また、個人による利用のように小口で散発的に利用するユーザでは、予め信頼しているＣＡがない場合が多く、さらに電子商取引に利用する端末自体の能力も限定されるために、電子商取引に要する時間がさらに大きくなり、ユーザの負担も大きくなるという問題点があった。
さらに、上述したようにデジタル署名は送信者を証明する手段に過ぎないため、商取引の相手として信頼に足るか否かの判断基準とはならない。特に商取引においては、データの送信元が信頼できるか否かの２値的な判断ではなく、どの程度信頼できるかが重要である。例えば、データの送信元によって取引金額の上限を幾らに設定するか、などの判断が求められる。特に数値的な信頼関係を計測できれば、将来の信頼値を予測することが可能となる。
すなわち、上述した従来のデジタル署名技術は、大規模なシステム間で頻繁にデータを送受信することが前提となっており、電子商取引の現状にそぐわないものであった。そのため、従来技術にかかる電子商取引では、公開鍵の認証に労力と時間とが必要となるとともに、送信元の取引相手としての信頼性を検証できないという問題点があった。
この発明は、上述した従来技術による問題点を解消するためになされたものであり、送信元の証明を簡易に実行可能で、送信元の信頼性を適切に評価可能な署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムを提供することを目的とする。
通信データの改竄を防止するため、従来、電子署名（デジタル署名）が用いられてきた。電子署名は公開鍵暗号を利用した技術であり、送信側は自らの秘密鍵を用いて署名を作成し、受信側は送信側の公開鍵を用いて署名を復号することで、署名の作成者が送信者に間違いがないことを確かめるものである。
この時、ＳＨＡ（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ）などの技術によって、データ内容のダイジェストを作成し、デジタル署名内部に含めることで、受信側はデータ内容が改竄されていないことを確認することが出来る。
ところで、このデジタル署名では、公開鍵が信頼できることが大前提となっている。すなわち、デジタル署名は公開鍵と秘密鍵が正しい対であることを示すに過ぎないので、悪意のある者が受信側に偽の公開鍵を渡すと共に、偽の秘密鍵によって作成したデータを送信したならば、受信側は偽の公開鍵でデータを復号できるがために、データ内容を信頼してしまうという問題が生じる。
そこで、デジタル署名を用いる場合には、認証局（ＣＡ）に公開鍵を登録し、ＣＡからの証明書を添付することで公開鍵の正当性を証明することが一般的である。
この認証局（ＣＡ）は、それぞれが信頼関係のネットワークを構築しているので、仮に送信側が登録したＣＡと受信側が利用しているＣＡとが異なる場合であっても、ＣＡ間のネットワークによって公開鍵の証明をおこなうことができる。
しかし、このＣＡ間のネットワークを用いて公開鍵の正当性を証明する処理は、受信者側に大きな負荷がかかる。そこで、たとえば特開２００２−１３９９９６号公報に公開された署名検証支援装置では、受信側に代わって送信側の公開鍵証明書の正当性を確認するようにしている。
しかしながら、このような従来のデジタル署名では、公開鍵の正当性を証明するために時間がかかるという問題点があった。近年、電子商取引の増加に伴い、処理速度の向上が求められているが、このような公開鍵の正当性証明する処理が処理遅延の原因となる。
また、個人による利用のように小口で散発的に利用するユーザでは、予め信頼しているＣＡがない場合が多く、さらに電子商取引に利用する端末自体の能力も限定されるために、電子商取引に要する時間がさらに大きくなり、ユーザの負担も大きくなるという問題点があった。
さらに、上述したようにデジタル署名は送信者を証明する手段に過ぎないため、商取引の相手として信頼に足るか否かの判断基準とはならない。特に商取引においては、データの送信元が信頼できるか否かの２値的な判断ではなく、どの程度信頼できるかが重要である。例えば、データの送信元によって取引金額の上限を幾らに設定するか、などの判断が求められる。特に数値的な信頼関係を計測できれば、将来の信頼値を予測することが可能となる。
すなわち、上述した従来のデジタル署名技術は、大規模なシステム間で頻繁にデータを送受信することが前提となっており、電子商取引の現状にそぐわないものであった。そのため、従来技術にかかる電子商取引では、公開鍵の認証に労力と時間とが必要となるとともに、送信元の取引相手としての信頼性を検証できないという問題点があった。
この発明は、上述した従来技術による問題点を解消するためになされたものであり、送信元の証明を簡易に実行可能で、送信元の信頼性を適切に評価可能な署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムを提供することを目的とする。
上述した課題を解決し、目的を達成するため、本発明に係る署名信頼性検証方法は、デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法であって、前記受信したデータから、信頼性の検証手続きを読み出す検証手続き読み出し工程と、前記検証手続き読み出し工程によって読み出した検証手続きに従って、当該データの信頼性を検証する信頼性検証工程と、を含んだことを特徴とする。
この発明によれば、受信したデータに含まれた信頼性の検証手続きを読み出して実行することで、受信したデータの信頼性を検証することができる。
また、本発明に係る署名信頼性検証方法では、前記検証手続きは、秘密鍵によって暗号化されたデジタル署名の対象に含まれることを特徴とする。
この発明によれば、秘密鍵によって暗号化されたデジタル署名の対象に含まれた信頼性の検証手続きを読み出して実行することで、受信したデータの信頼性を検証することができる。
また、本発明に係る署名信頼性検証方法では、前記検証手続きは、信頼性の高さによって分類された複数のクラスのいずれかに対する検証手続きであることを特徴とする。
この発明によれば、信頼性の高さによって分類された複数のクラスについて、それぞれ異なる検証手続きを対応させ、データの内容によって必要な信頼性の高さに対応する検証手続きを実行することができる。
また、本発明に係る署名信頼性検証方法は、前記検証手続き読み出し工程によって読み出した検証手続きの妥当性を確認する検証手続き確認工程をさらに含んだことを特徴とする。
この発明によれば、信頼性の検証手続き自体の妥当性を確認することで、データの信頼性をさらに正確に検証することができる。
また、本発明に係る署名信頼性検証方法は、前記受信したデータに前記信頼性検証工程による検証結果を付加して他の端末装置に送信する転送工程をさらに含めることにより、例えば信頼性９０％の検証者が付加した信頼性８０％の結果を信頼性７２％として判断できることを特徴とする。
この発明によれば、受信したデータの信頼性を検証した後、検証結果を付加して他の端末に転送することで、信頼性の検証に必要な能力を有さない端末であっても信頼性を検証したデータ通信が可能となる。
また、本発明に係る署名信頼性検証プログラムは、デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法をコンピュータに実行させる署名信頼性検証プログラムであって、前記受信したデータから、信頼性の検証手続きを読み出す検証手続き読み出し手順と、前記検証手続き読み出し手順によって読み出した検証手続きに従って、当該データの信頼性を検証する信頼性検証手順と、をコンピュータに実行させることを特徴とする。
この発明によれば、受信したデータに含まれた信頼性の検証手続きを読み出して実行させ、受信したデータの信頼性を検証することができるプログラムを実現できる。
また、本発明に係るデータ通信システムは、送信側端末が自端末の秘密鍵を用いて作成した署名を付してデータを送信し、受信側端末が送信側端末の公開鍵を用いて前記署名を復号するデータ通信ステムであって、前記送信側端末は、データ内容の信頼性を検証する検証手続きを指定する検証手続き指定手段を備え、該指定された検証手続きを前記署名対象の内部に含めて送信し、前記受信側端末は、前記署名対象の検証手続きに従って当該データ内容の信頼性を検証することを特徴とする。
この発明によれば、送信側端末がデータ内容の信頼性を検証する検証手続きを署名対象の内部に含めて送信し、受信側端末が署名対象から取り出した検証手続きを実行することで、受信したデータの信頼性を検証することができる。
この発明によれば、受信したデータに含まれた信頼性の検証手続きを読み出して実行することで、受信したデータの信頼性を検証することができる。
また、本発明に係る署名信頼性検証方法では、前記検証手続きは、秘密鍵によって暗号化されたデジタル署名の対象に含まれることを特徴とする。
この発明によれば、秘密鍵によって暗号化されたデジタル署名の対象に含まれた信頼性の検証手続きを読み出して実行することで、受信したデータの信頼性を検証することができる。
また、本発明に係る署名信頼性検証方法では、前記検証手続きは、信頼性の高さによって分類された複数のクラスのいずれかに対する検証手続きであることを特徴とする。
この発明によれば、信頼性の高さによって分類された複数のクラスについて、それぞれ異なる検証手続きを対応させ、データの内容によって必要な信頼性の高さに対応する検証手続きを実行することができる。
また、本発明に係る署名信頼性検証方法は、前記検証手続き読み出し工程によって読み出した検証手続きの妥当性を確認する検証手続き確認工程をさらに含んだことを特徴とする。
この発明によれば、信頼性の検証手続き自体の妥当性を確認することで、データの信頼性をさらに正確に検証することができる。
また、本発明に係る署名信頼性検証方法は、前記受信したデータに前記信頼性検証工程による検証結果を付加して他の端末装置に送信する転送工程をさらに含めることにより、例えば信頼性９０％の検証者が付加した信頼性８０％の結果を信頼性７２％として判断できることを特徴とする。
この発明によれば、受信したデータの信頼性を検証した後、検証結果を付加して他の端末に転送することで、信頼性の検証に必要な能力を有さない端末であっても信頼性を検証したデータ通信が可能となる。
また、本発明に係る署名信頼性検証プログラムは、デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法をコンピュータに実行させる署名信頼性検証プログラムであって、前記受信したデータから、信頼性の検証手続きを読み出す検証手続き読み出し手順と、前記検証手続き読み出し手順によって読み出した検証手続きに従って、当該データの信頼性を検証する信頼性検証手順と、をコンピュータに実行させることを特徴とする。
この発明によれば、受信したデータに含まれた信頼性の検証手続きを読み出して実行させ、受信したデータの信頼性を検証することができるプログラムを実現できる。
また、本発明に係るデータ通信システムは、送信側端末が自端末の秘密鍵を用いて作成した署名を付してデータを送信し、受信側端末が送信側端末の公開鍵を用いて前記署名を復号するデータ通信ステムであって、前記送信側端末は、データ内容の信頼性を検証する検証手続きを指定する検証手続き指定手段を備え、該指定された検証手続きを前記署名対象の内部に含めて送信し、前記受信側端末は、前記署名対象の検証手続きに従って当該データ内容の信頼性を検証することを特徴とする。
この発明によれば、送信側端末がデータ内容の信頼性を検証する検証手続きを署名対象の内部に含めて送信し、受信側端末が署名対象から取り出した検証手続きを実行することで、受信したデータの信頼性を検証することができる。
第１図は、データ通信システムにおけるデジタル署名の信頼性検証方法について説明する説明図であり、第２図は、検証方法の具体例について説明する説明図であり、第３図は、発注側端末の具体的な処理動作を説明するフローチャートであり、第４図は、受注側端末の処理動作を説明するフローチャートであり、第５図は、本実施の形態２にかかるデータ通信システムの概要構成を説明する説明図である。
以下に添付図面を参照して、この発明に係る署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムの好適な実施の形態を詳細に説明する。
（実施の形態１）
第１図は、データ通信システムにおけるデジタル署名の信頼性検証方法について説明する説明図である。同図に示すように、発注側端末１０は、受注側端末３０に発注データ２０を送信する場合に、発注者の信頼性を検証する方法を指定した検証方法データ２１を付加している。したがって、受注側端末３０は、この検証方法データ２２に示された検証方法に基づいて発注側端末１０の信頼性を検証することができる。
信頼性を検証するための方法としては任意の方法を用いることができるが、ここでは検証用データベース４に検証用のデータを保存しておくとともに、検証方法データ２２に検証用データの保存先を指定することで、受注側端末３０が検証用データベース４から検証用のデータを読み出せるようにしている。
具体的には発注側端末１０は、その内部に伝票作成部１１、検証方法指定部１２、署名作成部１３、証明書取得部１４を有する。伝票作成部１１は、注文品目や数量、金額の情報を含む伝票データ２１を作成する処理をおこなう。また、検証方法指定部１２は、受注側端末３０が信頼性を検証する際に用いる検証方法を指定し、検証方法データ２２を作成する。
一方、署名作成部１３は、伝票作成部１１が作成した伝票データ２１および検証方法データ２３のダイジェストを作成し、ダイジェストを発注側端末１０の秘密鍵１０ａを用いて暗号化し、署名２３を作成する。このダイジェストは、ハッシュ関数などを用いてデータ内容から一意に定まるデータ列を算出したものである。ここで、ダイジェストを作成する際には、ダイジェストがデータ内容から一意に定まることに加え、ダイジェストから元のデータの推測ができないことが望ましい。このダイジェスト作成方法としてはＳＨＡなどが広く用いられている。
ところで、発注側端末１０は、認証局（ＣＡ）２を信頼しており、秘密鍵１０ａに対応する公開鍵をＣＡ２に登録している。証明書取得部１４は、このＣＡ２から公開鍵の証明書２４を受信し、発注データ２０に追加する処理をおこなう。
すなわち、発注データ２０は、伝票データ２１、検証方法データ２２、署名２３および証明書２４を有することとなる。
受注側端末３０は、署名検証部３１、検証方法チェック部３３および検証処理部３４を有している。特に、検証方法の指定により、検証処理部３４は通常の証明書検証を行ってもよい。受注側端末３０が発注データ２０を受信した場合、署名検証部３１は、発注側端末１０の公開鍵を使って署名２３を復号して伝票データ２１および検証方法データ２２における改竄の有無を確認する。
また、検証処理部３４が証明書検証を行うときには、発注データ２０から証明書２４を読み出して、認証局（ＣＡ）３に証明書の問い合わせをおこなう。ここで、受注側端末３０が信頼しているＣＡ３は、発注側端末１０が信頼しているＣＡ２とは異なる。しかし、ＣＡ２およびＣＡ３は、それぞれＣＡ１を信頼することで信頼関係のネットワークを構築しているので、ＣＡ３は、ＣＡ１に問い合わせを行なってＣＡ２が信頼できると判定することができ、信頼に足るＣＡ２が発行した証明書１４を信頼することができる。
さらに検証方法チェック部３３は、検証方法データ２２によって示された検証方法が妥当なものであるか否かを判定し、検証処理部３４は、検証方法データ２２によって示された検証方法を用いて発注側端末１０の信頼性を検証する。
ここで、検証方法データ２２に示される検証方法の具体列について説明する。第２図は、検証方法の具体例について説明する説明図である。同図では、「指定されたＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）から証明書を取り出し、取り出した証明書と署名データとを比較する」という検証方法が示されており、検証用データとして「ＵＲＩ＝‘ｈｔｔｐ：／／ｘｘｘｘ／・・・」または「ＵＲＩ＝‘ｈｔｔｐ：／／ｙｙｙｙ／・・・」を指定している。
これらのＵＲＩは、検証用データベース４上の記憶領域を指定するネットワークアドレスである。したがって、受信側端末４０は、このＵＲＩを参照して検証用データベース４から指定された検証用データを読み出すことができる。
さらに、それぞれの検証用データには、取引の上限金額が設定されている。より具体的には、「ＵＲＩ＝‘ｈｔｔｐ：／／ｘｘｘｘ／・・・」に対しては上限金額「１００万円」が設定されており、「ＵＲＩ＝‘ｈｔｔｐ：／／ｙｙｙｙ／・・・」に対しては上限金額「５０００円」が設定されている。このように、検証用データごとにそれぞれ異なる上限金額を割り当てることで、取引の金額に応じて異なる検証を行うことができる。
したがって、低額の商取引用の検証用データを用いて取引相手を信頼したとしても、高額の取引を許可したことにならず、低額取引時に構築した信頼関係を悪用されて高額な損害が発生するという被害を防ぐことができる。
換言するならば、本発明にかかる通信システムでは、データの送信元が信頼できるか否かの２値的な判断ではなく、どの程度信頼できるかを取引金額の上限として判断することが可能となる。
つぎに、検証方法自体の妥当性の確認について説明する。検証方法の妥当性を確認するためには、たとえば過去の取引実績を証明すればよい。具体的には、過去の取引実績から成立した取引金額の最大値や、成立しなかった取引金額の最小値を求めることができる。そこで、これらの金額から、その取引相手と取引可能な金額を判定することが可能である。また、複数の保険などのサービスにその信頼性について金額の算出を依頼し、金額の平均やメジャーを算出しても良い。この保険などのサービスを用いる場合、インターネットなどのネットワーク上で依頼可能なサービスを利用したならば、検証方法の妥当性の確認と検証方法の実行を全てネットワーク上で実現可能である。
このように、検査方法の妥当性を確認可能とすることで、ＣＡからの証明書に依存することなく取引相手の信頼性を検証することが可能となる。すなわち、本発明にかかる信用性の検証では、取引相手の簡易的な証明を行うこととなり、ＣＡからの証明書を確認することが困難である場合や、証明書の確認までに要する時間が長すぎる場合などに、この簡易かつ高速な信用性の検証によってＣＡからの証明書に代えることができる。
特に低額取引などの場合のように、厳密に証明書を確認する事よりも高速にある程度の信頼性を確保する事が優先される場合や、受信側の端末に予め信頼しているＣＡが無い・証明書の確認に必要な能力が無い場合などに有用である。
さらに、ＣＡからの証明書が送信者を証明する手段に過ぎないのに対し、この信用性の検証は、商取引の相手として信頼に足るか否かの判断基準として利用することが可能である。特に、同一の公開鍵や署名であっても、異なる検証法を指定することによって取引金額に対応した信用性を確認することができる。
つぎに、発注側端末１０の具体的な処理動作について説明する。第３図は、発注側端末１０の具体的な処理動作を説明するフローチャートである。同図に示すように、発注側端末１０が発注データ２０を作成する場合、まず、伝票作成部１１によって伝票データ２１を作成する（ステップＳ１０１）。つぎに、検証方法指定部１２が、検証方法を指定して検証方法データ２２を作成する（ステップＳ１０２）。
その後、署名作成部１３は，伝票データ２１および検証方法データ２２のダイジェストをＳＨＡによって作成し、秘密鍵１０ａで暗号化して署名２３を作成する（ステップＳ１０３）。つづいて、証明書作成部１４は、秘密鍵１０ａに対応する公開鍵の証明書２４をＣＡ２から取得する（ステップＳ１０４）。
その後、検証方法指定部１２は、自らが指定した検証処理を実行し（ステップＳ１０５）、所望の信頼性が得られるか否かを検証する。このように、発注データ２０の送信前に検証処理を実行しておくことで、受注側端末３０における検証の結果として得られる信頼性の値を確認し、商取引に必要な信頼性が得られるか、また、必要以上の信頼性を付与していないかを確かめることができる。なお、ステップＳ１０５による事前の検証処理は、必要に応じて省略してもよい。
ステップＳ１０５の結果、所望の信頼性が得られなかった場合（ステップＳ１０６，Ｎｏ）、検証方法指定部１２は、検証方法を指定しなおす（ステップＳ１０２）。
一方、ステップＳ１０５の結果、所望の信頼性が得られたならば（ステップＳ１０６，Ｙｅｓ）、発注側端末１０は、伝票データ２１、検証方法データ２２、署名２３および証明書２４を発注データ２０として受注側端末３０に送信する。
つぎに、受注側端末３０の具体的な処理動作について説明する。第４図は、受注側端末３０の処理動作を説明するフローチャートである。同図に示すように、受注側端末３０は、発注データ２０を受信したならば（ステップＳ１０１）、署名検証部３１が発注データ２０の署名２３を読み出し、発注側端末１０の公開鍵を用いて書名を復号し、署名２３を検証する。この署名の検証は、具体的には、発注データ２０に含まれていた伝票データ２１および検証方法データ２２のダイジェストをＳＨＡによって作成し、署名２３に含まれていたダイジェスト、すなわち発注側端末１０で作成されたダイジェストと比較する処理である。
ＳＨＡによるダイジェストの作成では、元のデータが同一でれば出力されるダイジェストも同一となる。一方、仮に伝票データ２１や検証方法データ２２が通信経路上で改竄されたならば、発注側端末１０で作成したダイジェストと受注側端末３０で作成したダイジェストとは異なる値になる。つまり、受注側端末１０で作成したダイジェストが、発注側端末１０で作成したダイジェストと異なったならば、そのデータは改竄されていると考えることができる。
署名検証部３１は、このダイジェストの比較を行い、署名が検証できなかった、すなわちダイジェストが一致しないならば（ステップＳ２０３，Ｎｏ）、データの改竄を検出したことを示す署名エラーを出力し（ステップＳ２０４）、処理を終了する。
一方、署名が検証できた、すなわちダイジェストが一致したならば（ステップＳ２０３，Ｙｅｓ）、つぎに、検証処理部３４が証明書検証を行う場合はＣＡの証明書を検証する（ステップＳ２０５）。具体的には、このＣＡの証明書の検証処理では、受信した証明書２４をＣＡの公開鍵を用いて検証することで、証明書２４が本当にＣＡによって発行されたものであることを確かめる。確かめる方法としては、検証方法に記述して、通常のように検証サーバに問い合わせるなどの方法を用いることができる。
検証方法データ２２に示された検証方法で、取引に必要な信頼性が検証できなかった場合（ステップＳ２０６，Ｎｏ）、検証処理部３４は、検証エラーを出力し（ステップＳ２０７）、処理を終了する。
検証方法データ２２に示された検証方法で、取引に必要な信頼性が検証できた場合（ステップＳ２０６，Ｙｅｓ）、つぎに、検証方法チェック部３３が検証方法の妥当性を検証する（ステップＳ２０８）。
このステップＳ２０８によって検証方法の妥当性が検証できなかったならば（ステップＳ２０９，Ｎｏ）、検証方法チェック部３３は、妥当性エラーを出力し（ステップＳ２１０）、処理を終了する。
一方、ステップＳ２０８によって検証方法の妥当性が検証できたならば（ステップＳ２０９，Ｙｅｓ）、全ての検証を完了して（ステップＳ２１１）、処理を終了する。
このように、署名２３および証明書２４の検証をおこなうとともに、発注側端末１０によって指定された検証方法を用いて信頼性の検証処理を行い、さらに検証方法自体の妥当性を評価することによって、発注側端末の取引相手としての信頼性を検証することができる。
なお、署名の検証、証明書などの信頼性の検証および検証方法の妥当性の評価は、必ずしも第４図に示した順序で行う必要はなく、必要に応じて処理順序を変更することができる。
また、既に説明したように、信頼性の検証は証明書の検証を含むことができるので、証明書の検証に代えることができる。
上述してきたように、本実施の形態１にかかるデータ通信システムでは、発注側端末１０が指定した検証方法によって発注側端末１０の信頼性を検証するので、発注側端末および送受信されたデータの信頼性をＣＡに依存することなく簡易に検証し、さらに発注側端末１０の取引相手としての信頼性を適切に評価することができる。
なお、上述した実施の形態１においては検証方法データ２２全体を発注データ２０に含ませるとともに、そのダイジェストを作成して署名２３に含ませることとしているが、検証方法データ２２のダイジェストを作成して署名２２に含ませて署名対象とするのではなく、検証方法データ２２全体を署名２２に含ませるようにしても良い。
（実施の形態２）
ところで、上記実施の形態１では、発注側端末が送信した発注データの信頼性を受注側端末が検証することとしているが、本発明に構成は必ずしもこれに限定されるものでなく、例えば発注側端末と受注側端末との間に介在するサーバにおいて発注側端末の信頼性を検証し、検証結果を受信側端末に送信することとしてもよい。本実施の形態２では、第５図を参照して通信の途中に介在するサーバ上で信頼性の検証をおこなうデータ通信システムについて説明する。
第５図は、本実施の形態２にかかるデータ通信システムの概要構成を説明する説明図である。同図に示すように発注側端末１０と受注側端末７０との通信は、受注側サーバ５０を介して行われる。
受注側サーバ５０は、発注データ２０を受信した場合に、実施の形態１に示した受注側端末３０と同様に、発注側端末１０の信頼性を検証した後、転送処理部５１によって発注データ６０を作成して受注側端末７０に送信する。したがって、受注側端末７０は、信頼性の検証が既に終了した発注データ６０を受信することとなる。
なお、その他の構成および動作は実施の形態１に示したデータ通信システムと同様であるので、同一の構成要素には同一の符号を付して説明を省略する。
受注側サーバ５０の具体的な処理動作は、第４図に示した実施の形態１における受注側端末３０の処理と略同一である。違いとしては、発注データ２０の検証が終了した後に，転送処理部５０が発注データ６０を作成して受信側端末７０に送信する点である。
この発注データ６０は、既に各種の検証が終了しているので、その内部に伝票データ２１と検証結果６１とを有する。受注側端末７０は、この検証結果６１を信頼度１００％のサーバで検証してもらうことにより、自端末で検証処理を行うことなく信頼度数値を取得することができる。
したがって、この実施の形態２に示したデータ通信システムでは、例えば受信側端末７０が携帯電話やＰＤＡ（携帯情報端末）などの処理能力が限定された端末であっても発注側端末および送受信されたデータの信頼性をＣＡに依存することなく簡易に検証し、さらに発注側端末１０の取引相手としての信頼性を適切に評価することができる。
なお、上述した実施の形態１および実施の形態２では、電子商取引を行う場合の発注側端末と受注側端末について説明したが、本発明の利用はこれに限定されるものではなく、データ通信において信頼性の確認をおこなう場合に広く適用することができる。
また、実施の形態１および実施の形態２で説明した署名検証方法は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
（実施の形態１）
第１図は、データ通信システムにおけるデジタル署名の信頼性検証方法について説明する説明図である。同図に示すように、発注側端末１０は、受注側端末３０に発注データ２０を送信する場合に、発注者の信頼性を検証する方法を指定した検証方法データ２１を付加している。したがって、受注側端末３０は、この検証方法データ２２に示された検証方法に基づいて発注側端末１０の信頼性を検証することができる。
信頼性を検証するための方法としては任意の方法を用いることができるが、ここでは検証用データベース４に検証用のデータを保存しておくとともに、検証方法データ２２に検証用データの保存先を指定することで、受注側端末３０が検証用データベース４から検証用のデータを読み出せるようにしている。
具体的には発注側端末１０は、その内部に伝票作成部１１、検証方法指定部１２、署名作成部１３、証明書取得部１４を有する。伝票作成部１１は、注文品目や数量、金額の情報を含む伝票データ２１を作成する処理をおこなう。また、検証方法指定部１２は、受注側端末３０が信頼性を検証する際に用いる検証方法を指定し、検証方法データ２２を作成する。
一方、署名作成部１３は、伝票作成部１１が作成した伝票データ２１および検証方法データ２３のダイジェストを作成し、ダイジェストを発注側端末１０の秘密鍵１０ａを用いて暗号化し、署名２３を作成する。このダイジェストは、ハッシュ関数などを用いてデータ内容から一意に定まるデータ列を算出したものである。ここで、ダイジェストを作成する際には、ダイジェストがデータ内容から一意に定まることに加え、ダイジェストから元のデータの推測ができないことが望ましい。このダイジェスト作成方法としてはＳＨＡなどが広く用いられている。
ところで、発注側端末１０は、認証局（ＣＡ）２を信頼しており、秘密鍵１０ａに対応する公開鍵をＣＡ２に登録している。証明書取得部１４は、このＣＡ２から公開鍵の証明書２４を受信し、発注データ２０に追加する処理をおこなう。
すなわち、発注データ２０は、伝票データ２１、検証方法データ２２、署名２３および証明書２４を有することとなる。
受注側端末３０は、署名検証部３１、検証方法チェック部３３および検証処理部３４を有している。特に、検証方法の指定により、検証処理部３４は通常の証明書検証を行ってもよい。受注側端末３０が発注データ２０を受信した場合、署名検証部３１は、発注側端末１０の公開鍵を使って署名２３を復号して伝票データ２１および検証方法データ２２における改竄の有無を確認する。
また、検証処理部３４が証明書検証を行うときには、発注データ２０から証明書２４を読み出して、認証局（ＣＡ）３に証明書の問い合わせをおこなう。ここで、受注側端末３０が信頼しているＣＡ３は、発注側端末１０が信頼しているＣＡ２とは異なる。しかし、ＣＡ２およびＣＡ３は、それぞれＣＡ１を信頼することで信頼関係のネットワークを構築しているので、ＣＡ３は、ＣＡ１に問い合わせを行なってＣＡ２が信頼できると判定することができ、信頼に足るＣＡ２が発行した証明書１４を信頼することができる。
さらに検証方法チェック部３３は、検証方法データ２２によって示された検証方法が妥当なものであるか否かを判定し、検証処理部３４は、検証方法データ２２によって示された検証方法を用いて発注側端末１０の信頼性を検証する。
ここで、検証方法データ２２に示される検証方法の具体列について説明する。第２図は、検証方法の具体例について説明する説明図である。同図では、「指定されたＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）から証明書を取り出し、取り出した証明書と署名データとを比較する」という検証方法が示されており、検証用データとして「ＵＲＩ＝‘ｈｔｔｐ：／／ｘｘｘｘ／・・・」または「ＵＲＩ＝‘ｈｔｔｐ：／／ｙｙｙｙ／・・・」を指定している。
これらのＵＲＩは、検証用データベース４上の記憶領域を指定するネットワークアドレスである。したがって、受信側端末４０は、このＵＲＩを参照して検証用データベース４から指定された検証用データを読み出すことができる。
さらに、それぞれの検証用データには、取引の上限金額が設定されている。より具体的には、「ＵＲＩ＝‘ｈｔｔｐ：／／ｘｘｘｘ／・・・」に対しては上限金額「１００万円」が設定されており、「ＵＲＩ＝‘ｈｔｔｐ：／／ｙｙｙｙ／・・・」に対しては上限金額「５０００円」が設定されている。このように、検証用データごとにそれぞれ異なる上限金額を割り当てることで、取引の金額に応じて異なる検証を行うことができる。
したがって、低額の商取引用の検証用データを用いて取引相手を信頼したとしても、高額の取引を許可したことにならず、低額取引時に構築した信頼関係を悪用されて高額な損害が発生するという被害を防ぐことができる。
換言するならば、本発明にかかる通信システムでは、データの送信元が信頼できるか否かの２値的な判断ではなく、どの程度信頼できるかを取引金額の上限として判断することが可能となる。
つぎに、検証方法自体の妥当性の確認について説明する。検証方法の妥当性を確認するためには、たとえば過去の取引実績を証明すればよい。具体的には、過去の取引実績から成立した取引金額の最大値や、成立しなかった取引金額の最小値を求めることができる。そこで、これらの金額から、その取引相手と取引可能な金額を判定することが可能である。また、複数の保険などのサービスにその信頼性について金額の算出を依頼し、金額の平均やメジャーを算出しても良い。この保険などのサービスを用いる場合、インターネットなどのネットワーク上で依頼可能なサービスを利用したならば、検証方法の妥当性の確認と検証方法の実行を全てネットワーク上で実現可能である。
このように、検査方法の妥当性を確認可能とすることで、ＣＡからの証明書に依存することなく取引相手の信頼性を検証することが可能となる。すなわち、本発明にかかる信用性の検証では、取引相手の簡易的な証明を行うこととなり、ＣＡからの証明書を確認することが困難である場合や、証明書の確認までに要する時間が長すぎる場合などに、この簡易かつ高速な信用性の検証によってＣＡからの証明書に代えることができる。
特に低額取引などの場合のように、厳密に証明書を確認する事よりも高速にある程度の信頼性を確保する事が優先される場合や、受信側の端末に予め信頼しているＣＡが無い・証明書の確認に必要な能力が無い場合などに有用である。
さらに、ＣＡからの証明書が送信者を証明する手段に過ぎないのに対し、この信用性の検証は、商取引の相手として信頼に足るか否かの判断基準として利用することが可能である。特に、同一の公開鍵や署名であっても、異なる検証法を指定することによって取引金額に対応した信用性を確認することができる。
つぎに、発注側端末１０の具体的な処理動作について説明する。第３図は、発注側端末１０の具体的な処理動作を説明するフローチャートである。同図に示すように、発注側端末１０が発注データ２０を作成する場合、まず、伝票作成部１１によって伝票データ２１を作成する（ステップＳ１０１）。つぎに、検証方法指定部１２が、検証方法を指定して検証方法データ２２を作成する（ステップＳ１０２）。
その後、署名作成部１３は，伝票データ２１および検証方法データ２２のダイジェストをＳＨＡによって作成し、秘密鍵１０ａで暗号化して署名２３を作成する（ステップＳ１０３）。つづいて、証明書作成部１４は、秘密鍵１０ａに対応する公開鍵の証明書２４をＣＡ２から取得する（ステップＳ１０４）。
その後、検証方法指定部１２は、自らが指定した検証処理を実行し（ステップＳ１０５）、所望の信頼性が得られるか否かを検証する。このように、発注データ２０の送信前に検証処理を実行しておくことで、受注側端末３０における検証の結果として得られる信頼性の値を確認し、商取引に必要な信頼性が得られるか、また、必要以上の信頼性を付与していないかを確かめることができる。なお、ステップＳ１０５による事前の検証処理は、必要に応じて省略してもよい。
ステップＳ１０５の結果、所望の信頼性が得られなかった場合（ステップＳ１０６，Ｎｏ）、検証方法指定部１２は、検証方法を指定しなおす（ステップＳ１０２）。
一方、ステップＳ１０５の結果、所望の信頼性が得られたならば（ステップＳ１０６，Ｙｅｓ）、発注側端末１０は、伝票データ２１、検証方法データ２２、署名２３および証明書２４を発注データ２０として受注側端末３０に送信する。
つぎに、受注側端末３０の具体的な処理動作について説明する。第４図は、受注側端末３０の処理動作を説明するフローチャートである。同図に示すように、受注側端末３０は、発注データ２０を受信したならば（ステップＳ１０１）、署名検証部３１が発注データ２０の署名２３を読み出し、発注側端末１０の公開鍵を用いて書名を復号し、署名２３を検証する。この署名の検証は、具体的には、発注データ２０に含まれていた伝票データ２１および検証方法データ２２のダイジェストをＳＨＡによって作成し、署名２３に含まれていたダイジェスト、すなわち発注側端末１０で作成されたダイジェストと比較する処理である。
ＳＨＡによるダイジェストの作成では、元のデータが同一でれば出力されるダイジェストも同一となる。一方、仮に伝票データ２１や検証方法データ２２が通信経路上で改竄されたならば、発注側端末１０で作成したダイジェストと受注側端末３０で作成したダイジェストとは異なる値になる。つまり、受注側端末１０で作成したダイジェストが、発注側端末１０で作成したダイジェストと異なったならば、そのデータは改竄されていると考えることができる。
署名検証部３１は、このダイジェストの比較を行い、署名が検証できなかった、すなわちダイジェストが一致しないならば（ステップＳ２０３，Ｎｏ）、データの改竄を検出したことを示す署名エラーを出力し（ステップＳ２０４）、処理を終了する。
一方、署名が検証できた、すなわちダイジェストが一致したならば（ステップＳ２０３，Ｙｅｓ）、つぎに、検証処理部３４が証明書検証を行う場合はＣＡの証明書を検証する（ステップＳ２０５）。具体的には、このＣＡの証明書の検証処理では、受信した証明書２４をＣＡの公開鍵を用いて検証することで、証明書２４が本当にＣＡによって発行されたものであることを確かめる。確かめる方法としては、検証方法に記述して、通常のように検証サーバに問い合わせるなどの方法を用いることができる。
検証方法データ２２に示された検証方法で、取引に必要な信頼性が検証できなかった場合（ステップＳ２０６，Ｎｏ）、検証処理部３４は、検証エラーを出力し（ステップＳ２０７）、処理を終了する。
検証方法データ２２に示された検証方法で、取引に必要な信頼性が検証できた場合（ステップＳ２０６，Ｙｅｓ）、つぎに、検証方法チェック部３３が検証方法の妥当性を検証する（ステップＳ２０８）。
このステップＳ２０８によって検証方法の妥当性が検証できなかったならば（ステップＳ２０９，Ｎｏ）、検証方法チェック部３３は、妥当性エラーを出力し（ステップＳ２１０）、処理を終了する。
一方、ステップＳ２０８によって検証方法の妥当性が検証できたならば（ステップＳ２０９，Ｙｅｓ）、全ての検証を完了して（ステップＳ２１１）、処理を終了する。
このように、署名２３および証明書２４の検証をおこなうとともに、発注側端末１０によって指定された検証方法を用いて信頼性の検証処理を行い、さらに検証方法自体の妥当性を評価することによって、発注側端末の取引相手としての信頼性を検証することができる。
なお、署名の検証、証明書などの信頼性の検証および検証方法の妥当性の評価は、必ずしも第４図に示した順序で行う必要はなく、必要に応じて処理順序を変更することができる。
また、既に説明したように、信頼性の検証は証明書の検証を含むことができるので、証明書の検証に代えることができる。
上述してきたように、本実施の形態１にかかるデータ通信システムでは、発注側端末１０が指定した検証方法によって発注側端末１０の信頼性を検証するので、発注側端末および送受信されたデータの信頼性をＣＡに依存することなく簡易に検証し、さらに発注側端末１０の取引相手としての信頼性を適切に評価することができる。
なお、上述した実施の形態１においては検証方法データ２２全体を発注データ２０に含ませるとともに、そのダイジェストを作成して署名２３に含ませることとしているが、検証方法データ２２のダイジェストを作成して署名２２に含ませて署名対象とするのではなく、検証方法データ２２全体を署名２２に含ませるようにしても良い。
（実施の形態２）
ところで、上記実施の形態１では、発注側端末が送信した発注データの信頼性を受注側端末が検証することとしているが、本発明に構成は必ずしもこれに限定されるものでなく、例えば発注側端末と受注側端末との間に介在するサーバにおいて発注側端末の信頼性を検証し、検証結果を受信側端末に送信することとしてもよい。本実施の形態２では、第５図を参照して通信の途中に介在するサーバ上で信頼性の検証をおこなうデータ通信システムについて説明する。
第５図は、本実施の形態２にかかるデータ通信システムの概要構成を説明する説明図である。同図に示すように発注側端末１０と受注側端末７０との通信は、受注側サーバ５０を介して行われる。
受注側サーバ５０は、発注データ２０を受信した場合に、実施の形態１に示した受注側端末３０と同様に、発注側端末１０の信頼性を検証した後、転送処理部５１によって発注データ６０を作成して受注側端末７０に送信する。したがって、受注側端末７０は、信頼性の検証が既に終了した発注データ６０を受信することとなる。
なお、その他の構成および動作は実施の形態１に示したデータ通信システムと同様であるので、同一の構成要素には同一の符号を付して説明を省略する。
受注側サーバ５０の具体的な処理動作は、第４図に示した実施の形態１における受注側端末３０の処理と略同一である。違いとしては、発注データ２０の検証が終了した後に，転送処理部５０が発注データ６０を作成して受信側端末７０に送信する点である。
この発注データ６０は、既に各種の検証が終了しているので、その内部に伝票データ２１と検証結果６１とを有する。受注側端末７０は、この検証結果６１を信頼度１００％のサーバで検証してもらうことにより、自端末で検証処理を行うことなく信頼度数値を取得することができる。
したがって、この実施の形態２に示したデータ通信システムでは、例えば受信側端末７０が携帯電話やＰＤＡ（携帯情報端末）などの処理能力が限定された端末であっても発注側端末および送受信されたデータの信頼性をＣＡに依存することなく簡易に検証し、さらに発注側端末１０の取引相手としての信頼性を適切に評価することができる。
なお、上述した実施の形態１および実施の形態２では、電子商取引を行う場合の発注側端末と受注側端末について説明したが、本発明の利用はこれに限定されるものではなく、データ通信において信頼性の確認をおこなう場合に広く適用することができる。
また、実施の形態１および実施の形態２で説明した署名検証方法は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
以上のように、本発明にかかる署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムは、送信元の証明簡易化および高速化、さらに送信元の信頼性の評価に対して有用である。
この発明は、デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法および署名信頼性検証プログラム、およびデジタル署名を用いたデータ通信システムに関し、特に、送受信されるデータの信頼性を検証可能な署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムに関する。
近年、インターネットなどのネットワークが普及するにつれて、ネットワーク通信におけるセキュリティ技術が重要となっている。特に、商取引などをネットワーク上で実現する電子商取引では、そのデータ内容の改竄をいかに防止するかが大きな課題である。
通信データの改竄を防止するため、従来、電子署名（デジタル署名）が用いられてきた。電子署名は公開鍵暗号を利用した技術であり、送信側は自らの秘密鍵を用いて署名を作成し、受信側は送信側の公開鍵を用いて署名を復号することで、署名の作成者が送信者に間違いがないことを確かめるものである。
この時、SHA（Secure Hash Algorithm）などの技術によって、データ内容のダイジェストを作成し、デジタル署名内部に含めることで、受信側はデータ内容が改竄されていないことを確認することが出来る。
ところで、このデジタル署名では、公開鍵が信頼できることが大前提となっている。すなわち、デジタル署名は公開鍵と秘密鍵が正しい対であることを示すに過ぎないので、悪意のある者が受信側に偽の公開鍵を渡すと共に、偽の秘密鍵によって作成したデータを送信したならば、受信側は偽の公開鍵でデータを復号できるがために、データ内容を信頼してしまうという問題が生じる。
そこで、デジタル署名を用いる場合には、認証局（ＣＡ）に公開鍵を登録し、ＣＡからの証明書を添付することで公開鍵の正当性を証明することが一般的である。
この認証局（ＣＡ）は、それぞれが信頼関係のネットワークを構築しているので、仮に送信側が登録したＣＡと受信側が利用しているＣＡとが異なる場合であっても、ＣＡ間のネットワークによって公開鍵の証明をおこなうことができる。
しかし、このＣＡ間のネットワークを用いて公開鍵の正当性を証明する処理は、受信者側に大きな負荷がかかる。そこで、たとえば特開２００２−１３９９９６号公報に公開された署名検証支援装置では、受信側に代わって送信側の公開鍵証明書の正当性を確認するようにしている。
しかしながら、このような従来のデジタル署名では、公開鍵の正当性を証明するために時間がかかるという問題点があった。近年、電子商取引の増加に伴い、処理速度の向上が求められているが、このような公開鍵の正当性を証明する処理が処理遅延の原因となる。
また、個人による利用のように小口で散発的に利用するユーザでは、予め信頼しているＣＡがない場合が多く、さらに電子商取引に利用する端末自体の能力も限定されるために、電子商取引に要する時間がさらに大きくなり、ユーザの負担も大きくなるという問題点があった。
さらに、上述したようにデジタル署名は送信者を証明する手段に過ぎないため、商取引の相手として信頼に足るか否かの判断基準とはならない。特に商取引においては、データの送信元が信頼できるか否かの２値的な判断ではなく、どの程度信頼できるかが重要である。例えば、データの送信元によって取引金額の上限を幾らに設定するか、などの判断が求められる。特に数値的な信頼関係を計測できれば、将来の信頼値を予測することが可能となる。
すなわち、上述した従来のデジタル署名技術は、大規模なシステム間で頻繁にデータを送受信することが前提となっており、電子商取引の現状にそぐわないものであった。そのため、従来技術にかかる電子商取引では、公開鍵の認証に労力と時間とが必要となるとともに、送信元の取引相手としての信頼性を検証できないという問題点があった。
この発明は、上述した従来技術による問題点を解消するためになされたものであり、送信元の証明を簡易に実行可能で、送信元の信頼性を適切に評価可能な署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムを提供することを目的とする。
上述した課題を解決し、目的を達成するため、本発明に係る署名信頼性検証方法は、デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法であって、前記データを受信する受信装置内部の検証処理部が前記受信したデータから、前記デジタル署名の信頼性の検証手続きを読み出す検証手続き読み出し工程と、前記検証処理部が前記検証手続き読み出し工程によって読み出した検証手続きに従って、前記デジタル署名の信頼性を検証する信頼性検証工程と、を含んだことを特徴とする。
この発明によれば、受信したデータに含まれた信頼性の検証手続きを読み出して実行することで、受信したデータの信頼性を検証することができる。
また、本発明に係る署名信頼性検証方法では、前記検証手続きは、秘密鍵によって暗号化されたデジタル署名の対象に含まれることを特徴とする。
この発明によれば、秘密鍵によって暗号化されたデジタル署名の対象に含まれた信頼性の検証手続きを読み出して実行することで、受信したデータの信頼性を検証することができる。
また、本発明に係る署名信頼性検証方法では、前記検証手続きは、信頼性の高さによって分類された複数のクラスのいずれかに対する検証手続きであることを特徴とする。
この発明によれば、信頼性の高さによって分類された複数のクラスについて、それぞれ異なる検証手続きを対応させ、データの内容によって必要な信頼性の高さに対応する検証手続きを実行することができる。
また、本発明に係る署名信頼性検証方法は、前記検証手続き読み出し工程によって読み出した検証手続きの妥当性を前記受信装置内部の検証方法チェック部が確認する検証手続き確認工程をさらに含んだことを特徴とする。
この発明によれば、信頼性の検証手続き自体の妥当性を確認することで、データの信頼性をさらに正確に検証することができる。
また、本発明に係る署名信頼性検証方法は、前記受信したデータに前記信頼性検証工程による検証結果を付加して他の端末装置に送信する転送工程をさらに含めることにより、例えば信頼性９０％の検証者が付加した信頼性８０％の結果を信頼性７２％として判断できることを特徴とする。
この発明によれば、受信したデータの信頼性を検証した後、検証結果を付加して他の端末に転送することで、信頼性の検証に必要な能力を有さない端末であっても信頼性を検証したデータ通信が可能となる。
また、本発明に係る署名信頼性検証プログラムは、デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法をコンピュータに実行させる署名信頼性検証プログラムであって、前記データを受信する受信装置として機能するコンピュータ内部の検証処理部が前記受信したデータから、前記デジタル署名の信頼性の検証手続きを読み出す検証手続き読み出し手順と、前記検証処理部が前記検証手続き読み出し手順によって読み出した検証手続きに従って、前記デジタル署名の信頼性を検証する信頼性検証手順と、をコンピュータに実行させることを特徴とする。
この発明によれば、受信したデータに含まれた信頼性の検証手続きを読み出して実行させ、受信したデータの信頼性を検証することができるプログラムを実現できる。
また、本発明に係るデータ通信システムは、送信側端末が自端末の秘密鍵を用いて作成した署名を付してデータを送信し、受信側端末が送信側端末の公開鍵を用いて前記署名を復号するデータ通信システムであって、前記送信側端末は、前記署名の信頼性を検証する検証手続きを指定する検証手続き指定手段を備え、該指定された検証手続きを前記署名対象の内部に含めて送信し、前記受信側端末は、前記署名対象の検証手続きに従って前記署名の信頼性を検証することを特徴とする。
この発明によれば、送信側端末がデータ内容の信頼性を検証する検証手続きを署名対象の内部に含めて送信し、受信側端末が署名対象から取り出した検証手続きを実行することで、受信したデータの信頼性を検証することができる。
以下に添付図面を参照して、この発明に係る署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムの好適な実施の形態を詳細に説明する。
（実施の形態１）
第１図は、データ通信システムにおけるデジタル署名の信頼性検証方法について説明する説明図である。同図に示すように、発注側端末１０は、受注側端末３０に発注データ２０を送信する場合に、発注者の信頼性、すなわち発注者のデジタル署名の信頼性を検証する方法を指定した検証方法データ２２を付加している。したがって、受注側端末３０は、この検証方法データ２２に示された検証方法に基づいて発注側端末１０の信頼性を検証することができる。
第１図は、データ通信システムにおけるデジタル署名の信頼性検証方法について説明する説明図である。同図に示すように、発注側端末１０は、受注側端末３０に発注データ２０を送信する場合に、発注者の信頼性、すなわち発注者のデジタル署名の信頼性を検証する方法を指定した検証方法データ２２を付加している。したがって、受注側端末３０は、この検証方法データ２２に示された検証方法に基づいて発注側端末１０の信頼性を検証することができる。
信頼性を検証するための方法としては任意の方法を用いることができるが、ここでは検証用データベース４に検証用のデータを保存しておくとともに、検証方法データ２２に検証用データの保存先を指定することで、受注側端末３０が検証用データベース４から検証用のデータを読み出せるようにしている。
具体的には発注側端末１０は、その内部に伝票作成部１１、検証方法指定部１２、署名作成部１３、証明書取得部１４を有する。伝票作成部１１は、注文品目や数量、金額の情報を含む伝票データ２１を作成する処理をおこなう。また、検証方法指定部１２は、受注側端末３０が信頼性を検証する際に用いる検証方法を指定し、検証方法データ２２を作成する。
一方、署名作成部１３は、伝票作成部１１が作成した伝票データ２１および検証方法データ２２のダイジェストを作成し、ダイジェストを発注側端末１０の秘密鍵１０ａを用いて暗号化し、署名２３を作成する。このダイジェストは、ハッシュ関数などを用いてデータ内容から一意に定まるデータ列を算出したものである。ここで、ダイジェストを作成する際には、ダイジェストがデータ内容から一意に定まることに加え、ダイジェストから元のデータの推測ができないことが望ましい。このダイジェスト作成方法としてはＳＨＡなどが広く用いられている。
ところで、発注側端末１０は、認証局（ＣＡ）２を信頼しており、秘密鍵１０ａに対応する公開鍵をＣＡ２に登録している。証明書取得部１４は、このＣＡ２から公開鍵の証明書２４を受信し、発注データ２０に追加する処理をおこなう。なお、ＣＡが発行する証明書はそのフォーマットが国際基準（ＩＳＯ９５９４−８）として制定されており、証明書には利用者の公開鍵を含むこととなっている。そのため、証明書２４は発注者端末１０の公開鍵を含むこととなる。
すなわち、発注データ２０は、伝票データ２１、検証方法データ２２、署名２３および証明書２４を有することとなる。
受注側端末３０は、署名検証部３１、検証方法チェック部３３および検証処理部３４を有している。特に、検証方法の指定により、検証処理部３４は検証方法データ２２に示された方法ではなく、通常の証明書検証、すなわちＣＡネットワークを利用した証明書検証を行ってもよい。受注側端末３０が発注データ２０を受信した場合、署名検証部３１は、発注側端末１０の公開鍵を使って署名２３を復号して伝票データ２１および検証方法データ２２における改竄の有無を確認する。
また、検証処理部３４が通常の証明書検証を行うときには、発注データ２０から証明書２４を読み出して、認証局（ＣＡ）３に証明書の問い合わせをおこなう。ここで、受注側端末３０が信頼しているＣＡ３は、発注側端末１０が信頼しているＣＡ２とは異なる。しかし、ＣＡ２およびＣＡ３は、それぞれＣＡ１を信頼することで信頼関係のネットワークを構築しているので、ＣＡ３は、ＣＡ１に問い合わせを行なってＣＡ２が信頼できると判定することができ、信頼に足るＣＡ２が発行した証明書１４を信頼することができる。
さらに検証方法チェック部３３は、検証方法データ２２によって示された検証方法が妥当なものであるか否かを判定し、検証処理部３４は、検証方法データ２２によって示された検証方法を用いて発注側端末１０の信頼性を検証する。
ここで、検証方法データ２２に示される検証方法の具体列について説明する。第２図は、検証方法の具体例について説明する説明図である。同図では、「指定されたＵＲＩ（Uniform Resource Identifier）から証明書を取り出し、取り出した証明書と署名データとを比較する」という検証方法が示されており、検証用データ、すなわち証明書の取得先として「ＵＲＩ＝‘ｈｔｔｐ：／／ｘｘｘｘ／・・・」または「ＵＲＩ＝‘ｈｔｔｐ：／／ｙｙｙｙ／・・・」を指定している。
これらのＵＲＩは、検証用データベース４上の記憶領域を指定するネットワークアドレスである。したがって、受信側端末４０は、このＵＲＩを参照して検証用データベース４から指定された検証用データを読み出すことができる。
さらに、それぞれの検証用データには、取引の上限金額が設定されている。より具体的には、「ＵＲＩ＝‘ｈｔｔｐ：／／ｘｘｘｘ／・・・」に対しては上限金額「１００万円」が設定されており、「ＵＲＩ＝‘ｈｔｔｐ：／／ｙｙｙｙ／・・・」に対しては上限金額「５０００円」が設定されている。このように、検証用データごとにそれぞれ異なる上限金額を割り当てることで、取引の金額に応じて異なる検証を行うことができる。
したがって、低額の商取引用の検証用データを用いて取引相手を信頼したとしても、高額の取引を許可したことにならず、低額取引時に構築した信頼関係を悪用されて高額な損害が発生するという被害を防ぐことができる。
換言するならば、本発明にかかる通信システムでは、データの送信元が信頼できるか否かの２値的な判断ではなく、どの程度信頼できるかを取引金額の上限として判断することが可能となる。
つぎに、検証方法自体の妥当性の確認について説明する。検証方法の妥当性を確認するためには、たとえば過去の取引実績を証明すればよい。具体的には、過去の取引実績から成立した取引金額の最大値や、成立しなかった取引金額の最小値を求めることができる。そこで、これらの金額から、その取引相手と取引可能な金額を判定することが可能である。また、複数の保険などのサービスにその信頼性について金額の算出を依頼し、金額の平均やメジャーを算出しても良い。この保険などのサービスを用いる場合、インターネットなどのネットワーク上で依頼可能なサービスを利用したならば、検証方法の妥当性の確認と検証方法の実行を全てネットワーク上で実現可能である。
このように、検査方法の妥当性を確認可能とすることで、受注側端末が予め信頼しているＣＡからの証明書に依存することなく取引相手の信頼性を検証することが可能となる。すなわち、本発明にかかる信用性の検証では、取引相手の簡易的な証明を行うこととなり、予め信頼しているＣＡからの証明書を確認することが困難である場合や、証明書の確認までに要する時間が長すぎる場合などに、この簡易かつ高速な信用性の検証によって予め信頼しているＣＡからの証明書に代えることができる。
特に低額取引などの場合のように、厳密に証明書を確認する事よりも高速にある程度の信頼性を確保する事が優先される場合や、受信側の端末に予め信頼しているＣＡが無い・証明書の確認に必要な能力が無い場合などに有用である。
さらに、ＣＡからの証明書が送信者を証明する手段に過ぎないのに対し、この信用性の検証は、商取引の相手として信頼に足るか否かの判断基準として利用することが可能である。特に、同一の公開鍵や署名であっても、異なる検証法を指定することによって取引金額に対応した信用性を確認することができる。
つぎに、発注側端末１０の具体的な処理動作について説明する。第３図は、発注側端末１０の具体的な処理動作を説明するフローチャートである。同図に示すように、発注側端末１０が発注データ２０を作成する場合、まず、伝票作成部１１によって伝票データ２１を作成する（ステップＳ１０１）。つぎに、検証方法指定部１２が、検証方法を指定して検証方法データ２２を作成する（ステップＳ１０２）。
その後、署名作成部１３は、伝票データ２１および検証方法データ２２のダイジェストをＳＨＡによって作成し、秘密鍵１０ａで暗号化して署名２３を作成する（ステップＳ１０３）。つづいて、証明書作成部１４は、秘密鍵１０ａに対応する公開鍵の証明書２４をＣＡ２から取得する（ステップＳ１０４）。
その後、検証方法指定部１２は、自らが指定した検証処理を実行し（ステップＳ１０５）、所望の信頼性が得られるか否かを検証する。このように、発注データ２０の送信前に検証処理を実行しておくことで、受注側端末３０における検証の結果として得られる信頼性の値を確認し、商取引に必要な信頼性が得られるか、また、必要以上の信頼性を付与していないかを確かめることができる。なお、ステップＳ１０５による事前の検証処理は、必要に応じて省略してもよい。
ステップＳ１０５の結果、所望の信頼性が得られなかった場合（ステップＳ１０６，Ｎｏ）、検証方法指定部１２は、検証方法を指定しなおす（ステップＳ１０２）。
一方、ステップＳ１０５の結果、所望の信頼性が得られたならば（ステップＳ１０６，Ｙｅｓ）、発注側端末１０は、伝票データ２１、検証方法データ２２、署名２３および証明書２４を発注データ２０として受注側端末３０に送信する。
つぎに、受注側端末３０の具体的な処理動作について説明する。第４図は、受注側端末３０の処理動作を説明するフローチャートである。同図に示すように、受注側端末３０は、発注データ２０を受信したならば（ステップＳ２０１）、署名検証部３１が発注データ２０の署名２３を読み出し、発注側端末１０の公開鍵を用いて署名を復号し、署名２３を検証する。この署名の検証は、具体的には、発注データ２０に含まれていた伝票データ２１および検証方法データ２２のダイジェストをＳＨＡによって作成し、署名２３に含まれていたダイジェスト、すなわち発注側端末１０で作成されたダイジェストと比較する処理である。
ＳＨＡによるダイジェストの作成では、元のデータが同一でれば出力されるダイジェストも同一となる。一方、仮に伝票データ２１や検証方法データ２２が通信経路上で改竄されたならば、発注側端末１０で作成したダイジェストと受注側端末３０で作成したダイジェストとは異なる値になる。つまり、受注側端末１０で作成したダイジェストが、発注側端末１０で作成したダイジェストと異なったならば、そのデータは改竄されていると考えることができる。
署名検証部３１は、このダイジェストの比較を行い、署名が検証できなかった、すなわちダイジェストが一致しないならば（ステップＳ２０３，Ｎｏ）、データの改竄を検出したことを示す署名エラーを出力し（ステップＳ２０４）、処理を終了する。
一方、署名が検証できた、すなわちダイジェストが一致したならば（ステップＳ２０３，Ｙｅｓ）、つぎに、検証処理部３４が証明書検証を行う場合はＣＡ２の証明書を検証する（ステップＳ２０５）。具体的には、このＣＡ２の証明書の検証処理では、受信した証明書２４をＣＡ２の公開鍵を用いて検証することで、証明書２４が本当にＣＡ２によって発行されたものであることを確かめる。確かめる方法としては、検証方法に記述して、通常のように検証サーバに問い合わせるなどの方法を用いることができる。
検証方法データ２２に示された検証方法で、取引に必要な信頼性が検証できなかった場合（ステップＳ２０６，Ｎｏ）、検証処理部３４は、検証エラーを出力し（ステップＳ２０７）、処理を終了する。
検証方法データ２２に示された検証方法で、取引に必要な信頼性が検証できた場合（ステップＳ２０６，Ｙｅｓ）、つぎに、検証方法チェック部３３が検証方法の妥当性を検証する（ステップＳ２０８）。
このステップＳ２０８によって検証方法の妥当性が検証できなかったならば（ステップＳ２０９，Ｎｏ）、検証方法チェック部３３は、妥当性エラーを出力し（ステップＳ２１０）、処理を終了する。
一方、ステップＳ２０８によって検証方法の妥当性が検証できたならば（ステップＳ２０９，Ｙｅｓ）、全ての検証を完了して（ステップＳ２１１）、処理を終了する。
このように、署名２３および証明書２４の検証をおこなうとともに、発注側端末１０によって指定された検証方法を用いて信頼性の検証処理を行い、さらに検証方法自体の妥当性を評価することによって、発注側端末の取引相手としての信頼性を検証することができる。
なお、署名の検証、証明書などの信頼性の検証および検証方法の妥当性の評価は、必ずしも第４図に示した順序で行う必要はなく、必要に応じて処理順序を変更することができる。
また、既に説明したように、信頼性の検証は証明書の検証を含むことができるので、証明書の検証に代えることができる。
上述してきたように、本実施の形態１にかかるデータ通信システムでは、発注側端末１０が指定した検証方法によって発注側端末１０の信頼性を検証するので、発注側端末および送受信されたデータの信頼性をＣＡネットワークに依存することなく簡易に検証し、さらに発注側端末１０の取引相手としての信頼性を適切に評価することができる。
なお、上述した実施の形態１においては検証方法データ２２全体を発注データ２０に含ませるとともに、そのダイジェストを作成して署名２３に含ませることとしているが、検証方法データ２２のダイジェストを作成して署名２２に含ませて署名対象とするのではなく、検証方法データ２２全体を署名２２に含ませるようにしても良い。
（実施の形態２）
（実施の形態２）
ところで、上記実施の形態１では、発注側端末が送信した発注データの信頼性を受注側端末が検証することとしているが、本発明に構成は必ずしもこれに限定されるものでなく、例えば発注側端末と受注側端末との間に介在するサーバにおいて発注側端末の信頼性を検証し、検証結果を受信側端末に送信することとしてもよい。本実施の形態２では、第５図を参照して通信の途中に介在するサーバ上で信頼性の検証をおこなうデータ通信システムについて説明する。
第５図は、本実施の形態２にかかるデータ通信システムの概要構成を説明する説明図である。同図に示すように発注側端末１０と受注側端末７０との通信は、受注側サーバ５０を介して行われる。
受注側サーバ５０は、発注データ２０を受信した場合に、実施の形態１に示した受注側端末３０と同様に、発注側端末１０の信頼性を検証した後、転送処理部５１によって発注データ６０を作成して受注側端末７０に送信する。したがって、受注側端末７０は、信頼性の検証が既に終了した発注データ６０を受信することとなる。
なお、その他の構成および動作は実施の形態１に示したデータ通信システムと同様であるので、同一の構成要素には同一の符号を付して説明を省略する。
受注側サーバ５０の具体的な処理動作は、第４図に示した実施の形態１における受注側端末３０の処理と略同一である。違いとしては、発注データ２０の検証が終了した後に，転送処理部５０が発注データ６０を作成して受信側端末７０に送信する点である。
この発注データ６０は、既に各種の検証が終了しているので、その内部に伝票データ２１と検証結果６１とを有する。受注側端末７０は、この検証結果６１を信頼度１００％のサーバで検証してもらうことにより、自端末で検証処理を行うことなく信頼度数値を取得することができる。
したがって、この実施の形態２に示したデータ通信システムでは、例えば受信側端末７０が携帯電話やＰＤＡ（携帯情報端末）などの処理能力が限定された端末であっても発注側端末および送受信されたデータの信頼性をＣＡネットワークに依存することなく簡易に検証し、さらに発注側端末１０の取引相手としての信頼性を適切に評価することができる。
なお、上述した実施の形態１および実施の形態２では、電子商取引を行う場合の発注側端末と受注側端末について説明したが、本発明の利用はこれに限定されるものではなく、データ通信において信頼性の確認をおこなう場合に広く適用することができる。
また、実施の形態１および実施の形態２で説明した署名検証方法は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
以上のように、本発明にかかる署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システムは、送信元の証明簡易化および高速化、さらに送信元の信頼性の評価に対して有用である。
Claims (7)
- デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法であって、
前記受信したデータから、信頼性の検証手続きを読み出す検証手続き読み出し工程と、
前記検証手続き読み出し工程によって読み出した検証手続きに従って、当該データの信頼性を検証する信頼性検証工程と、
を含んだことを特徴とする署名信頼性検証方法。 - 前記検証手続きは、秘密鍵によって暗号化されたデジタル署名の中に含まれることを特徴とする請求の範囲第１項に記載の署名信頼性検証方法。
- 前記検証手続きは、信頼性の高さによって分類された複数のクラスのいずれかに対する検証手続きであることを特徴とする請求の範囲第１項または第２項に記載の署名信頼性検証方法。
- 前記検証手続き読み出し工程によって読み出した検証手続きの妥当性を確認する検証手続き確認工程をさらに含んだことを特徴とする請求の範囲第１項、第２項または第３項に記載の署名信頼性検証方法。
- 前記受信したデータに前記信頼性検証工程による検証結果を付加して他の端末装置に送信する転送工程をさらに含んだことを特徴とする署名信頼性検証方法。
- デジタル署名が施されたデータを受信し、当該データの信頼性を検証する署名信頼性検証方法をコンピュータに実行させる署名信頼性検証プログラムであって、
前記受信したデータから、信頼性の検証手続きを読み出す検証手続き読み出し手順と、
前記検証手続き読み出し手順によって読み出した検証手続きに従って、当該データの信頼性を検証する信頼性検証手順と、
をコンピュータに実行させることを特徴とする署名信頼性検証プログラム。 - 送信側端末が自端末の秘密鍵を用いて作成した署名を付してデータを送信し、受信側端末が送信側端末の公開鍵を用いて前記署名を復号するデータ通信ステムであって、
前記送信側端末は、データ内容の信頼性を検証する検証手続きを指定する検証手続き指定手段を備え、該指定された検証手続きを前記署名の内部に含めて送信し、
前記受信側端末は、前記署名の対象から取り出した検証手続きに従って当該データ内容の信頼性を検証することを特徴とするデータ通信システム。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2003/005831 WO2004100444A1 (ja) | 2003-05-09 | 2003-05-09 | 署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPWO2004100444A1 true JPWO2004100444A1 (ja) | 2006-07-13 |
Family
ID=33428599
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2004571571A Pending JPWO2004100444A1 (ja) | 2003-05-09 | 2003-05-09 | 署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システム |
Country Status (2)
| Country | Link |
|---|---|
| JP (1) | JPWO2004100444A1 (ja) |
| WO (1) | WO2004100444A1 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4785691B2 (ja) * | 2006-09-20 | 2011-10-05 | 富士通株式会社 | 正当性保証システム、正当性保証方法、および、プログラム。 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10313308A (ja) * | 1997-05-13 | 1998-11-24 | Nippon Telegr & Teleph Corp <Ntt> | ホームページ認証方法及び装置 |
| US6026166A (en) * | 1997-10-20 | 2000-02-15 | Cryptoworx Corporation | Digitally certifying a user identity and a computer system in combination |
| JPH11175512A (ja) * | 1997-12-09 | 1999-07-02 | Hitachi Ltd | 文書の存在証明に関するプログラム |
| JP4410324B2 (ja) * | 1998-10-16 | 2010-02-03 | 富士通株式会社 | 資格管理方法および装置 |
| US6567913B1 (en) * | 1998-12-24 | 2003-05-20 | Pitney Bowes Inc. | Selective security level certificate meter |
| JP2000331088A (ja) * | 1999-03-12 | 2000-11-30 | Mitsubishi Electric Corp | 認定マーク管理システムおよび認定マーク管理方法 |
| JP3696445B2 (ja) * | 1999-08-25 | 2005-09-21 | 日本電信電話株式会社 | 公開鍵証明証の発行方法並びに利用者端末及び認証センタ装置並びにこれらのプログラムを記録した媒体 |
| JP2002208960A (ja) * | 2001-01-11 | 2002-07-26 | Fuji Xerox Co Ltd | 電子メール装置 |
| JP2002351966A (ja) * | 2001-05-24 | 2002-12-06 | Hitachi Ltd | セキュアアーカイブ装置 |
-
2003
- 2003-05-09 JP JP2004571571A patent/JPWO2004100444A1/ja active Pending
- 2003-05-09 WO PCT/JP2003/005831 patent/WO2004100444A1/ja active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004100444A1 (ja) | 2004-11-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9736146B2 (en) | Embedded extrinsic source for digital certificate validation | |
| JP4681554B2 (ja) | 安全な移動体通信及び高価な取引の実行に対しランタイムパッケージ署名において信頼性の高いハードウェアベースのアイデンティティ信任状を使用する方法 | |
| US20070136599A1 (en) | Information processing apparatus and control method thereof | |
| US20020004800A1 (en) | Electronic notary method and system | |
| US20060206433A1 (en) | Secure and authenticated delivery of data from an automated meter reading system | |
| US20050138365A1 (en) | Mobile device and method for providing certificate based cryptography | |
| US20020073310A1 (en) | Method and system for a secure binding of a revoked X.509 certificate to its corresponding certificate revocation list | |
| US12008145B2 (en) | Method and server for certifying an electronic document | |
| US7058619B2 (en) | Method, system and computer program product for facilitating digital certificate state change notification | |
| JP2002164884A (ja) | プロキシサーバ、電子署名システム、電子署名検証システム、ネットワークシステム、電子署名方法、電子署名検証方法、記憶媒体及びプログラム伝送装置 | |
| WO2009028794A2 (en) | Method for providing anonymous public key infrastructure and method for providing service using the same | |
| CN112199721A (zh) | 认证信息处理方法、装置、设备及存储介质 | |
| JPWO2003003329A1 (ja) | データのオリジナリティ検証方法及びシステム | |
| US7853991B2 (en) | Data communications system and data communications method | |
| KR101253683B1 (ko) | 연쇄 해시에 의한 전자서명 시스템 및 방법 | |
| JP4846464B2 (ja) | 複数公開鍵の証明書を発行及び検証するシステム、並びに、複数公開鍵の証明書を発行及び検証する方法 | |
| JP3717848B2 (ja) | 電子公証システム及び電子公証方法 | |
| WO2004012415A1 (en) | Electronic sealing for electronic transactions | |
| US20090210719A1 (en) | Communication control method of determining whether communication is permitted/not permitted, and computer-readable recording medium recording communication control program | |
| KR100609701B1 (ko) | 전자 거래 내역에 대한 프라이버시를 보호하는 거래 인증방법 및 시스템 | |
| JP2002229451A (ja) | データ作成日時保証システム、データ作成日時保証方法、及びデータ作成日時保証プログラム | |
| JPWO2004100444A1 (ja) | 署名信頼性検証方法、署名信頼性検証プログラムおよびデータ通信システム | |
| CN111369332A (zh) | 基于区块链的数据处理方法及装置 | |
| JP2004341897A (ja) | 属性証明情報生成装置、属性証明情報要求装置、属性証明情報発行システム、属性認証システム | |
| JP4682268B1 (ja) | 識別情報の確認方法、識別情報を確認するためのサーバ装置および識別情報を確認するためのシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060606 |