Method and device for digital signature
Abstract
This record has no abstract on file.
Term
Term ended
Expired 6 October 2020, 6 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
18 claims: 7 independent, 11 dependent
- 1メッセージに対するディジタル署名を生成するディジタル署名生成装置であって、 署名生成時に作成する署名ログ L が一つ以上登録されたログリストを格納した記憶手段と、 前記ログリストを参照して新たなディジタル署名を生成する署名生成手段と、 前記新たなディジタル署名の生成時に新たな署名ログを生成して前記ログリストに登録する登録手段と、を備え、 i 番目の前記署名ログ L i は、前記 ディジタル署名生成装置が受信した 受信済みのメッセージM i に対して生成した署名値S i と、前記署名データを特定する署名識別子ID i と、前記受信済みのメッセージM i のハッシュ値h(M i )と、前記受信済みのメッセージM i より一つ前に受信したメッセージM i -1 に対する署名ログL i -1 に含まれる署名値S i -1 と、前記受信済みのメッセージM i -1 のハッシュ値h(M i -1 )と、からなる前データP i -1 のハッシュ値h(P i -1 )と、からなり、 前記署名生成手段は、前記ログリストを参照し、前記ログリストにすでに登録されている、受信済みメッセージM N-1 に対する署名ログL N-1 に含まれる前データP N-1 のハッシュ値h(P N-1 )を計算する手段と、前記署名対象であるメッセージM N のハッシュ値h(M N )と、計算した、前記前データP N-1 のハッシュ値h(P N-1 )と、を含むデータに対して、当該ディジタル署名生成装置に記憶されている秘密鍵を用いて、署名値S N を生成する手段と、を備え、 前記登録手段は、前記署名対象である受信メッセージM N と、前記署名対象である受信メッセージM N に対する署名ログL N と、を前記ログリストに登録する 手段を備える ことを特徴とするディジタル署名生成装置 。
- 2請求項1に記載のディジタル署名生成装置であって、さらに、 前記署名対象メッセージM N および/または前記署名対象メッセージM N に対する署名ログL N を、他の装置へ送信する送信手段を備える ことを特徴とするディジタル署名生成装置 。
- 3請求項1または2に記載のディジタル署名生成装置であって、さらに、 前記記憶手段に格納された署名ログを公開する公開手段を備える ことを特徴とするディジタル署名生成装置 。
- 4請求項1ないし3いずれか一に記載のディジタル署名生成装置であって、さらに、 前記前データP N-1 のハッシュ値h(P N-1 )を計算する手段は、前記前データP N-1 として、前記ログリストにすでに登録されている、受信したメッセージM N-2 に対する署名ログL N-2 に含まれる前記データP N-2 のハッシュ値をさらに計算の対象とする ことを特徴とするディジタル署名生成装置 。
- 5請求項1ないし4いずれか一に記載のディジタル署名生成装置であって、 前記署名ログL i は、さらに、当該署名ログに含まれる署名値を生成する際に用いた秘密鍵に対応する公開鍵に関わる公開鍵証明書に対応付けられる情報を含む ことを特徴とするディジタル署名生成装置 。
- 6請求項1に記載のディジタル署名生成装置によって生成された、メッセージに対するディジタル署名を検証するディジタル署名検証装置であって、 前記ディジタル署名S N と、前記署名対象メッセージM N と、を受け付ける検証対象受付手段と、 検証対象の前記ディジタル署名に対応する署名ログL N より後に前記ログリストに登録された署名ログを取得する履歴取得手段、と、 取得した前記署名ログに含まれる、前記署名ログL N よりあとに前記ログリストに登録され、かつ、信頼する署名ログL N+T 以前に前記ログリストに登録された、取得した前記署名ログL i に対し、前記署名ログL i に含まれる前データ のハッシュ値 h( P i -1 ) が、前記署名ログL i の一つ前に登録された署名ログL i -1 に含まれる 署名値 S i-1 とメッセージ M i-1 のハッシュ値 h(M i-1 ) とからなる データを前記ハッシュ関数の入力としたときに計算されるハッシュ値と一致するか否かを検証する連鎖検証手段と、を備える ことを特徴とするディジタル署名検証装置 。
- 7請求項6に記載のディジタル署名の検証装置であって、さらに、 前記検証対象受付手段が受け付けた検証対象となる署名ログL N が、前記履歴取得手段が取得した前記署名ログに登録されているか否かを調べる登録状態検証手段を備える ことを特徴とするディジタル署名検証装置 。
- 8請求項6または7に記載のディジタル署名の検証装置であって、 前記信頼する署名ログとは、前記検証対象となるディジタル署名S N よりあとに前記ディジタル署名生成装置において生成されたディジタル署名に関わる署名ログであって、当該署名ログ L N+T または当該署名ログ L N+T のハッシュ値 h(L N+T ) が、前記連鎖検証手段による検証が実行される以前に、公開された署名ログである ことを特徴とするディジタル署名検証装置 。
- 9請求項6ないし8いずれか一に記載のディジタル署名の検証装置であって、 前記ディジタル署名検証装置と、前記ディジタル署名生成装置は、同一の装置であって、 前記履歴取得手段は、前記ディジタル署名生成装置において前記記憶手段にあらかじめ格納されている、前記ログリストに含まれる前記署名ログ、を参照する ことを特徴とするディジタル署名検証装置 。
- 10電子計算機を、メッセージに対するディジタル署名を生成するディジタル署名生成装置として動作させる、ディジタル署名生成プログラムが記憶された記憶媒体であって、前記プログラムは、前記電子計算機に、 記憶手段に、署名生成時に作成する署名ログが一つ以上登録されたログリストを格納する処理と、 前記ログリストを参照して新たなディジタル署名を生成する署名生成処理と、 前記新たなディジタル署名の生成時に新たな署名ログを生成して前記ログリストに登録する登録処理と、を実行させ、 i 番目の前記署名ログL i は、前記 ディジタル署名生成装置が受信した 受信済みのメッセージM i に対して生成した署名値S i と、前記署名データを特定する署名識別子ID i と、前記受信済みのメッセージM i のハッシュ値h(M i )と、前記受信済みのメッセージM i より一つ前に受信したメッセージM i -1 に対する署名ログL i -1 に含まれる、署名値S i -1 と、前記受信済みのメッセージM i -1 のハッシュ値h(M i -1 )と、からなる前データP i -1 のハッシュ値h(P i -1 )と、からなり、 前記署名生成処理は、前記ログリストを参照し、前記ログリストにすでに登録されている、受信済みメッセージM N-1 に対する署名ログL N-1 に含まれる前データP N-1 のハッシュ値h(P N-1 )を計算する処理と、 前記署名対象であるメッセージM N のハッシュ値h(M N )と、計算した、前記前データP N-1 のハッシュ値h(P N-1 )と、を含むデータに対して、当該電子計算機に記憶されている秘密鍵を用いて、署名値S N を生成する処理と、からなり、 前記登録処理は、前記署名対象である受信メッセージM N と、前記署名対象である受信メッセージM N に対する署名ログL N と、を前記ログリストに登録する 処理からなる ことを特徴とするディジタル署名生成プログラムが記憶された記憶媒体 。
- 11請求項10に記載の ディジタル署名生成 プログラムが記憶された記憶媒体であって、 前記ディジタル署名生成プログラムは、さらに、前記電子計算機に、 前記署名対象メッセージM N および/または前記署名対象メッセージM N に対する署名ログL N を、他の装置へ送信する送信処理を実行させる ことを特徴とするディジタル署名生成プログラムが記憶された記憶媒体 。
- 12請求項10または11に記載の ディジタル署名生成 プログラムが記憶された記憶媒体であって、 前記ディジタル署名生成プログラムは、さらに、前記電子計算機に、 前記記憶手段に格納された署名ログを公開する公開処理を実行させる ことを特徴とするディジタル署名生成プログラムが記憶された記憶媒体 。
- 13請求項10ないし12いずれか一に記載の ディジタル署名生成 プログラムが記憶された記憶媒体であって、 前記前データP N-1 のハッシュ値h(P N-1 )を計算する処理は、前記前データP N-1 として、前記ログリストにすでに登録されている、受信したメッセージM N-2 に対する署名ログL N-2 に含まれる前記データP N-2 のハッシュ値をさらに計算の対象とする ことを特徴とするディジタル署名生成プログラムが記憶された記憶媒体 。
- 14請求項10ないし13いずれか一に記載の ディジタル署名生成 プログラムが記憶された記憶媒体であって、 前記署名ログL i は、さらに、当該署名ログに含まれる署名値を生成する際に用いた秘密鍵に対応する公開鍵に関わる公開鍵証明書に対応付けられる情報を含む ことを特徴とするディジタル署名生成プログラムが記憶された記憶媒体 。
- 15電子計算機を、請求項1または10に記載のディジタル署名生成装置によって生成された、メッセージに対するディジタル署名を検証するディジタル署名検証装置として動作させる、ディジタル署名検証プログラムが記憶された記憶媒体であって、 前記プログラムは、前記電子計算機に、 前記ディジタル署名S N と、前記署名対象メッセージM N と、を受け付ける検証対象受付処理と、 検証対象の前記ディジタル署名に対応する署名ログL N より後に前記ログリストに登録された署名ログを取得する履歴取得処理、と、 取得した前記署名ログに含まれる、前記署名ログL N よりあとに前記ログリストに登録され、かつ、信頼する署名ログL N+T 以前に前記ログリストに登録された、取得した前記署名ログL i に対し、前記署名ログL i に含まれる前データ のハッシュ値 h( P i -1 ) が、前記署名ログL i の一つ前に登録された署名ログL i -1 に含まれる 署名値 Si-1 とメッセージ Mi-1 のハッシュ値 h(Mi-1) とからなる データを前記ハッシュ関数の入力としたときに計算されるハッシュ値と一致するか否かを検証する連鎖検証処理と、を実行させる ことを特徴とするディジタル署名検証プログラムが記憶された記憶媒体 。
- 16請求項15に記載の ディジタル署名検証 プログラムが記憶された記憶媒体であって、 前記ディジタル署名検証プログラムは、さらに、前記電子計算機に、 前記検証対象受付処理が受け付けた検証対象となる署名ログL N が、前記履歴取得処理が取得した前記署名ログに登録されているか否かを調べる登録状態検証処理を実行させる ことを特徴とするディジタル署名検証プログラムが記憶された記憶媒体 。
- 17請求項15または16に記載の ディジタル署名検証 プログラムが記憶された記憶媒体であって、 前記信頼する署名ログとは、前記検証対象となるディジタル署名S N よりあとに前記ディジタル署名生成装置において生成されたディジタル署名に関わる署名ログ L N+T であって、当該署名ログ ログ L N+T または当該署名ログ ログ L N+T のハッシュ値 h(L N+T ) が、前記連鎖検証処理による検証が実行される以前に公開された , 署名ログである ことを特徴とするディジタル署名検証プログラムが記憶された記憶媒体 。
- 18請求項15ないし17いずれか一に記載の ディジタル署名検証 プログラムが記憶された記憶媒体であって、 前記ディジタル署名検証プログラムは、前記ディジタル署名生成装置において実行され、 前記履歴取得処理は、前記ディジタル署名生成装置において前記記憶手段にあらかじめ格納されている、前記ログリストに含まれる前記署名ログを参照する ことを特徴とするディジタル署名検証プログラムが記憶された記憶媒体 。
Independent claims18
161 paragraphs, as filed
[Technical field to which the invention belongs] The present invention relates to a digital signature technique.
[0002] Conventional Technology Digital signature, which is a technology for imparting a function equivalent to a conventional seal to a digitized message such as an electronic document, enables advanced use of a network in electronic commerce and the like. It is attracting attention as a technology.
[0003] Documents relating to digital signature technology include, for example, the following.
[0004] Reference 1: Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone, "Handbook of Applied Cryptography" CRC Press, Inc. 1997 Reference 2: Bruce Schneier, "Applied Cryptography Second Edition", Jogn Wiley & Sons, Inc. 1996 Reference 3: International Application Number PCT / US91 / 05386 Reference 4: "Standerd Specifications for Public Key Cryptography (Draft Version 11)" IEEE P1363, IEEE, July 1999 The digital signature technology described in each of the above documents generates a digital signature. A person generates a digital signature A for a message M by applying a secret key that he / she keeps secretly to the message M to be signed, its characteristic value, and a hash value that is a message digest. Then, the message M is published with the digital signature A attached. The digital signature verifier compares the result obtained by operating the digital signature A attached to the message M with the public key paired with the private key with the message M or its hash value. If they do not match, message M may have been tampered with after the digital signature A was generated.
[0005] Therefore, it is authenticated that the digital signature A is made to the message M only when the two match.
[0006] In P75, "CHAPTER4 Intermediate Protocols, 4.1 TIMESTANPING SERVICES" and Document 3 of Document 2 above, the digital signature generator creates a new digital signature by modifying the message generated by the digital signature generator. However, techniques for preventing fraudulent activities such as replacing these with the original message and digital signature are disclosed. In this technique, the digital signature generator is the message M to be signed.<sub>n</sub>Or the hash value and the previous digital signature A<sub>n-1</sub>Message M by operating a private key that keeps the signature target data and time data of<sub>n</sub>Digital signature for A<sub>n</sub>To generate. In this way, the digital signature A<sub>n</sub>Digital signature generated after A<sub>n + 1</sub>The digital signature A that was generated one before<sub>n</sub>The data to be signed is reflected. Therefore, the message M generated by the digital signature generator itself.<sub>n</sub>New digital signature A with some tampering<sub>n</sub>And these are the original message M<sub>n</sub>And digital signature A<sub>n</sub>If you commit a fraudulent act that replaces with Digital Signature A<sub>n + 1</sub>It becomes inconsistent with.
[0007] [Problems to be Solved by the Invention] By the way, in the above-mentioned digital signature technology, it is premised that the digital signature generator keeps his / her own private key secretly. That is, it is assumed that only the digital signature generator holding the private key can generate a digital signature that can be verified by using the public key paired with the private key.
[0008] When a third party illegally obtains the private key of the digital signature generator and impersonates the digital signature generator to perform a digital signature for some reason such as improper management of the private key of the digital signature generator, the above Digital signature technology cannot detect this.
[0009] In International Application Number PCT / US93 / 1117, a new digital signature for a message is generated by applying a new private key held by the digital signature generator to the message and the digital signature for the message. The technology to be used is disclosed. However, with this technology, there is a possibility that a third party can illegally obtain the private key of the digital signature generator due to the dramatic improvement in the computing power of the electronic computer in recent years and the improvement of the algorithm for obtaining the private key from the public key. This is a technology for ensuring the security of digital signatures that was previously performed when the number of digital signatures has increased. It is the detection of digital signatures that a third party who illegally obtained a private key impersonates a digital signature generator. Can't.
[0010] The present invention has been made in view of the above circumstances, and an object of the present invention is to obtain a digital signature made by the digital signature generator itself and a digital signature made by a third party impersonating the digital signature generator. The purpose is to provide an identifiable digital signature technology.
[Means for Solving the Problems] In order to achieve the above object, the first aspect of the present invention is to distribute a digitally signed message including the generated digital signature and a message on the digital signature generator side. Prior to, the log data of the digitally signed message is registered in the log list. Here, the log data may be the digitally signed message itself, or may be a digitally signed message in which the message included in the digitally signed message is replaced with the hash value of the message.
[0012] The hash value used in the present invention refers to a value calculated by a function called a hash function, which outputs a fixed-length value from an arbitrary-length input. For the purpose of ensuring safety, use a function that makes it difficult to find two different input values that give the same output value and to find an input value that gives an output to a given value. Is desirable. It is assumed that the hash function algorithm is open to the entire system.
[0013] By doing so, the digital signature verifier obtains a log list from the digital signature generator and checks whether or not the log data of the digitally signed message to be verified is registered in the log list. This makes it possible to verify whether or not the digitally signed message to be verified is distributed by the digital signature generator.
[0014] Further, in the second aspect of the present invention, the digital signature generator side transmits a digital signature for the message generated by itself to a time stamp issuing station which is a reliable third party, and the time stamp issuing station. Encrypts the digital signature and time data using the private key that is kept secretly, and asks them to generate a time stamp. Then, this time stamp is attached to the message and distributed.
By doing so, the digital signature verifier obtains the time data and the digital signature from the time stamp attached to the message by using the private key of the time stamp issuing authority and the public key paired with the private key. By examining whether the date and time indicated by the time data has passed the date and time notified in advance by the digital signature generator, it is possible to verify whether or not the digital signature is valid by the digital signature generator. It becomes.
[Embodiment of the Invention] FIG. 1 is a schematic view of a system to which the first embodiment of the present invention is applied.
As illustrated, this system is a digital signer-side device 1 that creates a digitally signed message.<sub>1</sub>~1<sub>n</sub>(Hereinafter, simply referred to as the digital signer side device 1) and the purchaser side device 3 that holds the digitally signed message created by the digital signer side device 1.<sub>1</sub>~3<sub>n</sub>(Hereinafter, simply referred to as the purchaser side device 3), the digital signature verifier side device 5 that verifies the digitally signed message created by the digital signer side device 1, and the message created by the digital signature side device 1. It is composed of an intermediary device 7 that publishes a list of devices and obtains a digitally signed message from the digital signer device 1 on behalf of the purchaser device 3.
[0018] In the embodiment of the present invention, the message has the same value as digital data such as an electronic document, digitized multimedia data such as image data and audio data, and securities. It shall also include digital data to be possessed. In addition, the wording "purchase" used in the description of the embodiment of the present invention refers to the act of obtaining a digitally signed message created by a digital signer by some method, regardless of whether it is paid or free of charge. ..
FIG. 2 is a schematic configuration diagram of a digital signature side device 1, a purchaser side device 3, a digital signature verifier side device 5, an intermediary side device 7, and a time stamp issuing device 8.
Each device is a reading device that reads data from a CPU 11, a RAM 12 that functions as a work area of the CPU 11, an external storage device 13 such as a hard disk device, and a portable storage medium 15 such as a CD-ROM or FD. 14, an input device 16 such as a keyboard and a mouse, a display device 17 such as a display, a communication device 18 for communicating with other devices via a network, an IC card connection device 19, and each of the above-described configurations. It can be constructed by connecting an IC card 22, which is a storage medium with a calculation function, to an electronic computer 21 having a general configuration and having an interface 20 that controls data transmission / reception between elements.
[0021] What is stored in the external storage device 13 of the digital signer side device 1 is to request the IC card 22 to generate a digital signature for the message, and attach the digital signature generated by the IC card 22 to the message. Then, the digital signature verifier side device 5 is requested to verify the signed message creation PG (program) 131 for distribution as a digitally signed message and the digitally signed message created by the own digital signer side device 1. , To provide the digital signature verifier side device 5 with the information necessary for the digital signature verifier side device 5 to verify the digitally signed message according to the instruction from the digital signature verifier side device 5. Verification request PG (program) 132. These are loaded on the RAM 12 and embodied by the CPU 11 as a process called a signed message creation processing unit 111 and a verification request processing unit 112.
[0022] The external storage device 13 of the purchaser side device 3 stores a signed message acquisition PG (program) 331 for obtaining a digitally signed message from the digital signature side device 1 and the obtained digital signature. This is a verification request PG (program) 332 for requesting the device 5 on the digital signature verifier side to verify the attached message. These are loaded on the RAM 12 and embodied by the CPU 11 as a process called a signed message acquisition processing unit 311 and a verification request processing unit 312.
[0023] What is stored in the external storage device 13 of the digital signature verifier side device 5 is a signature verification PG that verifies the digitally signed message according to the instruction from the digital signature side device 1 or the purchaser side device. (Program) 531. This is loaded on RAM12 and embodied by CPU11 as a process called signature verification processing unit 511.
[0024] The intermediary side device 7 obtains a digitally signed message from the digital signer side device 1 on behalf of the purchaser side device 3. Basically, it has the same configuration as in FIG. The purchaser-side device 3, the digital signature verifier-side device 5, and the intermediary-side device 7 do not have to have an IC card connection device.
[0025] These programs may be read from the portable storage medium 15 such as a CD-ROM or FD by the reading device 14 and installed in the external storage device 13, or the communication device 18 may be installed. It may be downloaded from the network to the external storage device 13 via the network.
FIG. 3 is a schematic configuration diagram of the IC card 22 shown in FIG.
As shown in the figure, the IC card 22 communicates with the computer 21 via the CPU 221 and the RAM 222 functioning as the work area of the CPU 221, the EEPROM 223 for storing various programs and data, and the IC card connecting device 19. Has I / O 224 to perform. In the present invention, EEPROM refers to a non-volatile memory in which data can be electrically rewritten.
[0028] The EEPROM 223 includes a signature generation PG (program) 2231 for generating a digital signature for a message, a private key 2232 used for digital signature generation, and a private key 2232 according to an instruction from the signed message creation processing unit 111. A public key certificate 2233 containing a public key paired with a private key 2232 and a signature log table 2234 for recording the history of digital signature generation are stored. Here, the signature generation PG2231 and the private key 2232 are set when the IC card 22 is issued, and are set so that they cannot be read from the outside of the IC card 22. Those that are written at the time of card issuance and are not rewritten afterwards, such as the signature generation PG2231, may be stored in a non-rewritable ROM instead of the EEPROM 223. The public key certificate 2233 is set when the IC card 22 is issued, and is set so that it can be read from outside the IC card 22.
[0029] Further, the signature log table 2234 is not recorded at all when the IC card 22 is issued, and each time the IC card 22 generates a digital signature, the generated digital signature and the hash value of the signature target message are displayed. The signature log 2235 consisting of the purchaser name (such as the address of the device 3 on the purchaser side) of the message to be signed is added. This signature log table 2234 can be read from the outside of the IC card 22, but is set so that it cannot be rewritten from the outside of the IC card 22 and the data cannot be erased. And. The example shown in FIG. 3 shows the state after N digital signature generation processes are performed on the IC card 22, and N signature logs 2235 are stored in the signature log table 2234.
[0030] The issuing process of the IC card 22, that is, the process of storing and setting the signature generation PG2231, the private key 2232, and the public key certificate 2233 in the EEPROM 223 may be performed by the IC card issuer. Alternatively, the IC card issuer issues the signature generation PG2231 in the EEPROM 223, and the digital signature who owns the IC card 22 stores the private key 2232 and the public key certificate 2233 in the EEPROM 223. You may set it.
When the digital signer stores and sets the private key 2232 in the EEPROM 223, the IC card issuer stores the private key generation program inside the IC card 22 in advance, and the digital signer executes it. Therefore, it is desirable that the digital signer himself stores and sets the value of the private key 2232 without knowing it.
[0032] The CPU 221 embodies the signature generation processing unit 2211 as a process by loading and executing the signature generation PG2231 on the RAM 222.
Next, with reference to FIG. 4, the operation when the purchaser-side device 3 obtains the digitally signed message from the digital signer-side device 1 will be described.
[0034] In the digital signer-side device 1, when the signed message creation processing unit 111 receives a message transmission request from the purchaser-side device 3, the message to be the transmission request is stored, for example, various messages. The hash value is obtained by reading from the external storage device 13 and evaluating this with a hash function. Then, the hash value of the message and the address of the purchaser-side device 3 that made the transmission request are sent to the signature generation processing unit 2211 to request signature generation (S6101). The signature generation processing unit 2211 applies the private key 2232 to the hash value of the sent message to generate a digital signature for the message (S6102). The signature generation processing unit 2211 registers the signature log 2235 consisting of the hash value of the message and the address of the purchaser-side device 3 that has made the digital signature and the transmission request in the signature log table 2234 (S6103), and digitally signs and the public key. The certificate 2233 is sent to the signed message composition processing unit 111. It is preferable that the signature log table 2234 can be indexed in advance so that data can be managed sequentially because it is easy to understand the temporal context between each signature log. The signed message creation processing unit 111 creates a digitally signed message by attaching the digital signature to the message to be sent, attaches the public key certificate 2233, and makes the sending request. Send to device 3 (S6104).
[0035] In the purchaser-side device 3, the signed message acquisition processing unit 311 receives a message acquisition request from the purchaser via the input device 36, and the digital signer-side device of the acquisition source that holds the message. Send a message transmission request to 1 (S6001), and wait for a digitally signed message to be sent from the digital signer side device 1 (S6002). The signed message acquisition processing unit 311 verifies the digital signature contained in the received digitally signed message. Specifically, the public key of the public key certificate 2233 attached to the digitally signed message is applied to the digital signature, and the hash value is obtained from the message included in the digitally signed message. Compare (S6003). If they match (S6004 is OK), it authenticates that the digital signature was made for the message contained in the digitally signed message, accepts the digitally signed message, and obtains it. The address of the device 1 on the digital signature side of is attached and stored in an external storage device 33 or the like (S6005). If they do not match (S6004 is NG), the digitally signed message is discarded without authentication (S6006).
[0036] Before actually accepting the digitally signed message, the purchaser's device makes a signature verification request, which will be described later, as necessary, for example, depending on the value of the digitally signed message. You may ask 5 to verify the signature and confirm that it is a valid signature before accepting it.
When the intermediary side device 7 acts on behalf of the purchaser side device 3, the intermediary side device 7 executes the flow of the purchaser side device 3 shown in FIG. 4 and purchases the signed message accepted by the S6005. It is transmitted to the user side device 3. In this case, since the purchaser-side device 3 does not have to perform the verification process shown in S6003, the burden on the purchaser-side device 3 can be reduced. The mediator side device 7 obtains information about the messages owned by each digital signer side device 1 in advance, and each purchaser side uses the Web or the like to display a list of messages owned by each digital signer side device 1 on the purchaser side. It is preferable to expose it to the device 3.
[0038] The digital signature side device 1 may create a digitally signed message based on the intention of the digital signer regardless of whether or not there is a request from the purchaser side device 3. In this case, the flow of the purchaser-side device 3 shown in FIG. 4 is not performed. However, the purchaser of the digitally signed message can verify the signature by requesting the digital signature verifier side device 5 to request the signature verification described later by using the purchaser side device 3.
[0039] For example, taking digital data in which a message has the same value as securities (here, referred to as electronic securities) as an example, the digital signer who is the issuer of the electronic securities is on the digital signer side. Using the device 1, the flow of the digital signature side device 1 shown in FIG. 4 is executed to create and issue a signed electronic security. Since the purchaser of the created signed electronic securities is not clear at the issuance stage of the electronic securities, the purchaser's address is not included in the signature log 2235 registered in the signature log table 2234.
[0040] The intermediary side device 7 obtains the signed electronic security issued by the digital signer side device 1 and publishes it on the Web or the like. Then, in response to the request from the purchaser-side device 3, the desired signed electronic security is sent or sent by mail or the like. A person who wishes to purchase electronic securities requests the digital signature verifier side device 5 to verify the electronic securities to be purchased using the purchaser side device 3 before actually performing the purchase procedure, and the validity is confirmed. Only then can the actual purchase procedure be carried out.
Next, using FIG. 5, the purchaser-side device 3 requests the digital signature-side device 5 to verify the digitally signed message obtained from the digital signature-side device 1. Will be described.
[0042] In the purchaser-side device 3, the verification request processing unit 312 receives a digital signature when the purchaser instructs the purchaser via the input device 36 to request verification of the digitally signed message held by the purchaser. The attached message is attached with the address of the digital signature side device 1 from which the digitally signed message is obtained, and is sent to the digital signature verifier side device 5 to request verification (S7001). It waits for the verification result to be sent from the digital signature verifier side device 5 (S7002), and displays the verification result on the display device 37, for example (S7003).
[0043] In the digital signature verification side device 5, when the signature verification processing unit 511 receives the verification request for the digitally signed message from the purchaser side device 3, the step is taken with respect to the digitally signed message sent together with the request. Similar to S6003 and S6004, the first stage verification is performed (S7101, S7102).
[0044] If S7102 is OK, authenticate and proceed to S7103. If the S7102 is NG, the verification result is sent to the purchaser-side device 3 that sent the verification request and the digital signer-side device 1 specified by the address attached to the digitally signed message without authentication (S7108). ).
[0045] In S7103, the signature verification processing unit 511 performs all signature logs 2235 (signature logs) recorded in the signature log table 2234 in the digital signer side device 1 specified by the address attached to the digitally signed message. Requesting the transmission of (referred to as a list) (S7103), waiting for the signature log list to be sent from the digital signature side device 1 (S7104), the signature verification processing unit 511 responds to the digitally signed message by the first step. Perform two-step verification. Specifically, it is checked whether or not the signature log including the digital signature included in the digitally signed message and the hash value of the message obtained by S7101 is registered in the obtained signature log list (S7105).
If registered (OK in S7106), the digitally signed message is authenticated as being legitimate generated by the digital signer side device 1 that submitted the signature log list, and the digitally signed message is authenticated. The result is transmitted to the purchaser-side device 3 that sent the verification request and the digital signer-side device 1 identified by the address attached to the digitally signed message (S7107).
If it is not registered (NG in S7106), the digitally signed message is not generated by the digital signer side device 1 that submitted the signature log list, that is, the private key 2232 by some method. The third party who obtained the certificate impersonates the digital signature, determines that it was generated improperly, and identifies the result by the purchaser-side device 3 that sent the verification request and the address attached to the digitally signed message. It is transmitted to the digital signer side device 1 (S7108).
[0048] In the digital signature verifier side device 1, the verification request processing unit 112 waits for the signature log list transmission request and the verification result to be sent from the digital signature verifier side device 5 (S7201). When a request to send the signature log list is sent, all the signature logs 2235 registered in the signature log table 2234 of EEPROM 223 are read and sent to the digital signature verifier side device 5 (S7202). When the verification result is sent (S7203), the contents are displayed on the display device 17 (S7204), for example. In this way, by transmitting the verification result to the device 1 on the digital signer side, for example, a third party who has acquired the private key 2232 by some method impersonates the digital signature and improperly signs the digital signature. If it indicates that it has been generated, it is possible to take measures such as changing the private key 2232 for signature generation.
[0049] In the present invention, the history log list is sent from the digital signature side device 1 to the digital signature verifier side device 5 by communication using a network as described above, for example, by mail. It may be done by sending the IC card 22 itself.
Next, using FIG. 6, when the digital signature side device 1 requests the digital signature verifier side device 5 to verify the digitally signed message generated by the own digital signature side device 1. The operation of is described.
In the digital signature side device 1, the verification request processing unit 112 receives the address of the purchaser side device 3, which is the purchaser of the digitally signed message, from the digital signer via the input device 16. When the request for verification of the digitally signed message is instructed, the input address of the purchaser side device 3 is transmitted to the digital signature verifier side device 5 to request verification (S8001). After that, the process proceeds to S8002, and the processes of S7201 to S7204 of the flow shown in FIG. 5 are executed.
[0052] In the digital signature verification side device 5, when the signature verification processing unit 511 receives a verification request for a digitally signed message from the digital signer side device 1, the purchaser specified by the address sent together with the request. A request to send a digitally signed message to be verified is sent to the side device 3 with the address of the digital signature side device 1 that sent the verification request (S8101), and the message is waited to be sent. (S8102). After that, the process proceeds to S8103, and the processes of S7101 to S7109 of the flow shown in FIG. 5 are executed.
[0053] In the purchaser-side device 3, the verification request processing unit 312 waits for the digital signature verifier-side device 5 to send a transmission request for the digitally signed message to be verified (S8201). Then, the digitally signed message obtained from the digital signature side device 1 specified by the address attached to the request is read from, for example, the external storage device 33 and transmitted to the digital signature verifier side device 5 (S8202). ). After that, the process proceeds to S8203, and the processes of S7002 to S7003 in the flow shown in FIG. 5 are executed.
[0054] According to the present embodiment, the device 1 on the digital signer side includes a signature log 2235 including a hash value of the digital signature and the message prior to distribution of the digitally signed message including the digital signature and the message generated by the digital signer side device 1. Is registered in the signature log table 2234.
[0055] The digital signature verifier side device 5 obtains a signature log list including signature logs 2235 registered from the digital signature generator side device 1, and has a hash value of the message included in the digitally signed message to be verified. And check whether the signature log including the digital signature is registered. By doing so, the digitally signed message to be verified is a legitimate one generated by the digital signer side device 1, or a third party who has acquired the private key 2232 by some method digitally signs it. It is possible to identify whether or not it was created illegally by impersonating a person.
[0056] Unlike the above embodiment, the signature log table may be set in the external storage device 13 included in the computer 21 in addition to the EEPROM 223. Then, by registering the newly generated signature log in the signature log table of EEPROM 223, the number of logs registered in the signature log table of EEPROM 223 is a predetermined number (this number may be set in consideration of the capacity of EEPROM 223). If the number exceeds, move the oldest log registered in the signature log table of EEPROM 223 to the signature log table of the external storage device 13, and then register the new signature log in the signature log table of EEPROM 223. May be good.
Alternatively, a plurality of signature logs registered in the signature log table of the EEPROM 223 may be collectively registered in the signature log table of the external storage device 13. The registration of the external storage device 13 in the signature log table may be appropriately performed according to the instruction of the signer, or may be automatically performed every time a predetermined number is reached.
Alternatively, the newly generated signature log is registered in each of the signature log table of the EEPROM 223 and the signature log table of the external storage device 13 of the computer 21, and the newly generated signature log is registered in the signature log table of the EEPROM 223. If the number of logs registered in the signature log table of EEPROM 223 exceeds the specified number by registering in, the oldest signature log registered in the signature log table of EEPROM 223 is deleted from the signature log table of EEPROM 223. Then, the newly generated signature log may be registered in the signature log table of EEPROM 223.
[0059] By doing so, it is possible to realize the digital signature side device 1 even when the capacity of the EEPROM 223 is small.
[0060] The signature log table set in the external storage device 13 is set to be writable only from the IC card 22 or rewritten such as a CD-R in order to prevent the digital signer from tampering with the signature log. It is preferable to use a storage medium that cannot be used.
[0061] Instead of setting the signature log table in the EEPROM 223, in addition to the configuration shown in FIG. 1, a signature log management device 9 that manages the signature log table for each digital signer side device 1 is newly provided. May be good. Then, the digital signature side device 1 may register the signature log in the signature log table associated with the own digital signer side device 1 each time a new digital signature is generated, or may be external. Similar to when registering in the signature log table of the storage device 13, it is decided to collect a plurality of signature logs and register them in the signature log table provided in association with the own digital signature side device 1 of the signature log management device 9. You may.
[0062] In this case, in S7103 of the flow shown in FIG. 5, the digital signature verifier side device 5 requests the signature log management device 9 to send the signature log list, and the digital signature verifier creates the verification target digitally signed message. This is done with the address of the device 1 on the signer side. The signature log management device 9 performs S7201 and S7202 in the flow shown in FIG.
[0063] When the signature log management device 9 receives a request for transmitting the signature log list, the signature log list of the digital signer side device 1 specified by the address attached to the request is changed to the digital signature verifier side device. Send to 5. By doing so, it is possible to prevent the digital signaturer from falsifying the signature log.
[0064] The signature log management device 9 may be constructed on the same computer as the device 5 on the digital signature verifier side, or may be constructed on both the same computer and a different computer, and the signature is first created. The logs may be managed by the signature log management device on the same computer, and when a certain number is reached, they may be collectively registered in the signature log management device on different computers.
[0065] If there is no privacy problem, the signature log data in the signature log management device 9 is disclosed to other devices connected by the network for a certain period of time or at all times after the signature is generated. You may leave it. However, it shall be set so that the log cannot be rewritten or deleted. This allows, for example, the purchaser to ensure that the records of the transactions in which he or she is involved are reflected in the signer's log and are viewable by many other devices. By managing the signature log, it becomes difficult for the signer to falsify the signature log data, so that the reliability of the entire system can be improved. The device for publishing the signature log may be provided separately from the signature log management device.
[0066] Unique information may be set for each IC card to ensure that the registered signature log is indeed related to the signature generated by the IC card 22. For example, when an IC card issuer issues an IC card, information unique to each IC card is secretly set for the signer who is the owner of each IC card. Every time the signature generation process is performed by the IC card, the information unique to the IC card is used as a private key for generating a MAC (Message Authentication Code), which is different from the private key 2232 for generating a digital signature. , Contact registered in the signature log table together with a signature log to generate a MAC for the digital signature can, in response to the transmission request of the signature log list from the digital signature verifier sends the signature log list containing the MAC ..
[0067] By the above method, falsification of the signature log can be made more difficult. This is because the digital signature verifier obtains the unique information of the IC card that generated the signature from the IC card issuer in advance or as needed, and uses it to confirm the validity of the MAC, thereby performing the signature log. This is because it can detect tampering with. Moreover, since the information that the signer himself does not know is used as the private key, it is possible to prevent the signature log from being forged by the signer himself.
[0068] Not only storing the MAC in the signature log table, but also outputting it to the purchaser together with a digitally signed message to reinforce the confirmation that the signature attached to the message purchased by the purchaser is valid. It may be made available as a means of doing so.
[0069] When the signature log management device 9 is provided and the signature log table is set in the signature log management device 9, the signature log management device 9 also needs the unique information of the IC card that generated the signature from the IC card issuer in advance or. When registering the signature log in the signature log table provided in the signature log management device 9, the validity of the MAC may be checked and only the correct one may be registered. In this case, when a signature log that does not satisfy the validity of the MAC is to be registered, it is considered that the signature can be forged because the private key for signature 2232 is exposed, and the signer or system It is possible to issue a warning to the whole and not use the private key or signature method thereafter.
[0070] Instead of using the information unique to each IC card as a private key for MAC generation, another digital signature to ensure that the signature is certainly generated by a specific IC card 22. Even if it is used as a private key, it is possible to make it difficult to forge the signature log as in the case of MAC. In the above method, the signature verification for confirming that the IC card 22 has generated does not require the unique information itself for each IC card, and there is public key information that can be obtained by anyone corresponding to the unique information. It's easy to use as a way for buyers to reinforce their confirmation that the signature on their purchased message is legitimate, unlike when using a MAC.
[0071] In the above method, from the viewpoint of avoiding the risk of forgery due to the improvement of the decryption algorithm, it is desirable to use a digital signature method different from the digital signature sent as a signed message to the purchaser, and in the IC card 22. From the viewpoint of reducing the scale of implementation of, it is advantageous to use the same digital signature method, so it may be selected according to the situation.
If the information unique to each IC card is dynamically updated, the private key information is not fixed, so that there is an advantage that the analysis of the private key becomes difficult. In the above method, it is necessary to know the updating means in order to confirm the validity by using the information unique to each original IC card. For example, after performing a process of using the unique information, a hash value of the unique information may be obtained and used as new unique information.
[0073] Next, a second embodiment that can more effectively prevent falsification of the signature log will be described. The configuration of each device of the system in the present embodiment is basically the same as that of the first embodiment except for the configuration of the signature log 2235 stored in the signature log table 2234.
[0074] The operation when the purchaser-side device 3 obtains the digitally signed message from the digital signer-side device 1 is the same as that of the first embodiment shown in FIG. 4, but the digital signer-side device 1 The specific processing content of signature generation in the above and the specific processing content of signature verification in the purchaser device 3 are different.
In the digital signer side device 1, the signature generation processing unit 2211 includes the message M included in the signature log 2235 generated by the previous (N-1th) signature generation processing.<sub>N</sub>Hash value h (M<sub>N-1</sub>) And digital signature Sign<sub>N-1</sub>Pair with (h (M)<sub>N-1</sub>), Sign<sub>N-1</sub>) (This is the previous data P<sub>N-1</sub>), And the message M sent from the signed message creation processing unit 111.<sub>N</sub>Hash value h (M<sub>N</sub>) And the private key 2232, digital signature Sign<sub>N</sub>Is generated (S6102). When generating the signature for the first time (first time), the previous data P<sub>0</sub>The initial value IV, which is determined in advance as a value common to the entire system or a value unique to each device, may be used, or may be set to "None". The signature generation processing unit 2211 is the previous data P.<sub>N-1</sub>And the hash value of the message h (M)<sub>N</sub>) And digital signature Sign<sub>N</sub>The signature log 2235 consisting of the address of the purchaser-side device 3 that made the transmission request is registered in the signature log table 2234 (S6103). Previous data P<sub>N-1</sub>And digital signature Sign<sub>N</sub>And the public key certificate 2233 stored in the EEPROM 223 is sent to the signed message creation processing unit 111. The signed message creation processing unit 111 is the message M that is the target of the transmission request.<sub>N</sub>Previous data P<sub>N-1</sub>And digital signature Sign<sub>N</sub>Create a digitally signed message with, attach the public key certificate 2233, and send it to the purchaser's device 3 (S6104).
[0076] In the above embodiment, the digital signature Sign<sub>N</sub>When generating the previous data P<sub>N-1</sub>Not the hash value h of the previous data (P)<sub>N-1</sub>) May be used. In this case, the data to be stored in the signature log table is also the previous data P<sub>N-1</sub>Instead of the hash value h of the previous data (P<sub>N-1</sub>) Is fine. In addition, the hash value h (M) of the message is used as the data before the Nth signature.<sub>N-1</sub>) And digital signature Sign<sub>N-1</sub>In addition to N-1 pre-data used when signing for the first time P<sub>N-2</sub>Hash value h (P<sub>N-2</sub>) May be used. Further, the hash function used to obtain the hash value for the message and the hash function used to obtain the hash value for the previous data may be different. Previous data P<sub>N-1</sub>As (h (M)<sub>N-1</sub>), Sign<sub>N-1</sub>), P<sub>i</sub>Even if (0 <i <N-1) is not saved, P is calculated from other data.<sub>N-1</sub>When is required, the previous data may not be saved in order to reduce the data storage area, and may be obtained by calculation if necessary.
By the above processing, the signature log 2235 stored in the signature log table 2234 is configured to include the previous data, the hash value of the message, and the digital signature, as shown in FIG. 7.
[0078] In the purchaser-side device 3, in the comparison step of S6003, not only the hash value obtained from the message included in the digitally signed message is compared, but the pre-data included in the digitally signed message is included in the comparison target. The pair with and is to be compared.
Next, using FIG. 8, the purchaser-side device 3 requests the digital signature-side device 5 to verify the digitally signed message obtained from the digital signature-side device 1. Will be described. In the following, the verification operation in a situation where the determination of "counterfeiting" is a disadvantageous result for the signer will be described as an example.
[0080] In FIG. 8, the processing of S11001, S11002, and S11003 is the same as that of S7001, S7002, and S7003 in FIG. 5, respectively.
[0081] When the verification request processing unit 312 receives a request from the digital signature verifier side device 5 to send a digitally signed message as reference material (S11101), the verification request processing unit 312 uses the address attached to the request. The digitally signed message obtained from the specified digital signature side device 1 is read from, for example, the external storage device 33 and transmitted to the digital signature verifier side device 5 (S11102).
[0082] In the digital signature verification side device 5, the signature verification processing unit 511 uses the digital signature included in the digitally signed message and the public key of the public key certificate 2233 attached to the digitally signed message. Then, the first stage verification is performed (S11201). When the signature is authenticated (processing of S11203 and S11204 when S11202 is OK) and when it is not authenticated (processing of S11214 when S11202 is NG), it is the same as S7103, S7104 and S7108, respectively.
[0083] The signature verification processing unit 511 verifies the digitally signed message in the second stage. Specifically, it is checked whether or not the signature log including the digital signature included in the digitally signed message and the previous data and the hash value of the message obtained in S11201 is registered in the obtained signature log list (S11205). ..
If it is registered (S11206 is OK), the same judgment as S7106 is made, and the third stage verification is performed on the digitally signed message. Specifically, in the signature log list obtained in S11204, the hash value and digital signature of the message included in the signature log registered one before the signature log corresponding to the digitally signed message to be verified. read out. For example, in FIG. 7, if the signature log containing the digital signature and the previous data contained in the digitally signed message to be verified and the hash value of the message obtained in S11201 is the Nth, the N-1th signature log is used. Read the hash value and digital signature of the contained message. The signature verification processing unit 511 compares the hash value of the message and the digital signature included in the previously registered signature log with the pre-data included in the digitally signed message to be verified. Here, as described above, the previous data is composed of the hash value of the message included in the signature log registered immediately before and the digital signature (S11207).
[0085] If the two do not match (NG in S11208), it is determined that the signature log corresponding to the digitally signed message to be verified has been tampered with, and the result is the purchaser's device that sent the verification request. It is sent to the digital signer side device 1 identified by 3 and the address attached to the digitally signed message (S11216). If they match (S11206 is OK), proceed to S11209.
[0086] In S11209, in the signature log list obtained in S11204, it is specified by the purchaser's address included in the signature log registered one before the signature log corresponding to the digitally signed message to be verified. A request to the purchaser side device 3 that the digitally signed message should be sent as reference material is made with the address of the digital signer side device 1 that sent the verification request, and the message is sent. Wait for (S11210).
[0087] The signature verification processing unit 511 verifies the digitally signed message obtained as reference material in the fourth stage.
[0088] Specifically, the hash value of the message included in the digitally signed message obtained in S11210 is obtained. Then, the digital signature and previous data included in the digitally signed message obtained in S11210 and the hash value of the message are 1 more than the signature log corresponding to the digitally signed message to be verified in the signature log list obtained in S11204. Check whether it matches the contents of the previously registered signature log (S11211).
If they do not match (NG in S11212), it corresponds to the signature log corresponding to the digitally signed message to be verified and the digitally signed message of the reference material recorded one before this. Both of the signature logs have been tampered with, and as a result, it is determined that the result of the third stage verification in S11208 may have been OK, and the result is digitally signed with the purchaser side device 3 that sent the verification request. It is transmitted to the digital signer side device 1 identified by the address attached to the message (S11217). If they match (S11212 is OK), the digitally signed message to be verified is authenticated as being legitimate generated by the digital signature device 1 that submitted the signature log list, and the result is Is sent to the purchaser-side device 3 that sent the verification request and to the digital signer-side device 1 identified by the address attached to the digitally signed message (S11213). The processing of steps S11301 to S11305 in the digital signature side device 1 is the same as that of steps S7201 to S7204.
Next, using FIG. 9, when the digital signature side device 1 requests the digital signature verifier side device 5 to verify the digitally signed message generated by the own digital signature side device 1. The operation of is described.
[0091] In the digital signature side device 1, in step S12001, the same processing as in S8001 is performed, and in S12002, the processing of S11301 to S11305 of the flow shown in FIG. 8 is executed.
[0092] In the digital signature verification side device 5, in steps S12101 and S12102, the same processing as in S8101 and S8102 is performed, and in S12103, the processing of S11201 to S11217 in the flow shown in FIG. 8 is executed.
[0093] In the purchaser-side device 3, in steps S12201 and S12203, the same processing as in S8201 and S8202 is performed, and in S12204, the processing of S11002 to S11003 in the flow shown in FIG. 8 is executed.
[0094] When a request for sending a digitally signed message as a reference material is sent from the device 5 on the digital signature verifier side (processing of S12202 when NO in S12201), the verification request processing unit 312 , The digitally signed message as a reference material obtained from the digital signature side device 1 specified by the address attached to the request is read and transmitted to the digital signature verifier side device 5 (S12205).
[0095] According to the present embodiment, it is possible to investigate the validity of the digitally signed message in more detail.
[0096] In the signature verification in the third stage of the above embodiment, the signature log corresponding to the digitally signed message to be verified, that is, the Nth signature log and the N-1th signature log immediately before the signature log. Check the consistency (whether the chain is maintained correctly), but also check the consistency between the N-1st signature log and the previous N-2nd signature log. You may do it. By changing this to check that the previous and next chains are properly maintained for more signature logs contained in the signature log list, the reliability of the signature log list can be checked in more detail. May be good.
[0097] In the signature verification in the third stage of the above embodiment, among all the signature logs recorded in the signature log table 2234, an arbitrary number including the signature log corresponding to the digitally signed message to be verified. The signature log tampering is detected by checking whether the previous data contained in the signature log matches the digital signature and message hash value contained in the previous signature log. May be good.
[0098] Checking whether or not the hash value of the digitally signed message is reflected in the digital signature included in one or more signature logs registered after the signature log corresponding to the digitally signed message. By doing so, the falsification of the signature log may be detected.
[0099] According to the present embodiment, in order to forge a past electronic signature, one or more electronic signatures must be consistently forged before or after the electronic signature to be forged is created. Will not be. This increases the difficulty of forging past electronic signatures, making it difficult to attack the correct business performer by forging the signature, and for the correct business performer, the alibi counterfeiting itself Putting it in a difficult position has the effect of increasing the proof of the mediator when exposed to malicious attacks.
[0100] In the above embodiment, in the signature verification in the second stage, if the signature data included in the digitally signed message to be verified is not included in the signature log list submitted by the signer, it is subject to verification. The digital signature was judged to be forged, and if it was included, the validity of the signature log list was confirmed in the third and fourth stages.
[0101] This is because it is unlikely that the signer will submit a tampered signature log list if the determination of "counterfeiting" is a disadvantageous result for the signer submitting the signature log list. is there.
[0102] On the contrary, when it is judged that the signature is "legitimate signature" is a disadvantageous result for the signer who submits the signature log list, the signature verification in the second stage is the verification target. If the signature data of is included in the submitted signature log list, it is judged to be valid, and if it is not included, the signature log list is valid in the 3rd and 4th stages. You may try to confirm the sex.
[0103] Alternatively, after receiving the signature log list in S11204, the validity of the signature log list is first confirmed, and then if the signature data to be verified is in the signature log list whose validity has been confirmed, it is valid. It may be determined that it is a signature.
[0104] When the signer cannot submit the entire signature log list to the verifier for some reason such as data destruction, it is generally submitted as (a part of) the signature log list. Although it is not possible to trust all of the information received, a reliable signature log can be extracted from the sent information by following the method shown below.
[0105] In the digital signature verification side device 5, among the signature logs included in the submitted signature log list, those with evidence that there is a signature corresponding to an area that the signer cannot control himself are reliable signature logs. Can be regarded as.
[0106] For example, the signature stored in the EEPROM 223 area as the signature log 2235 is automatically written when the signer generates the signature using the IC card 22. Since this area is set so that it cannot be rewritten or erased, it cannot be controlled (tampered with) by the signer himself. Therefore, the log corresponding to the signature stored in the EEPROM 223 area may be considered reliable.
Similarly, since the signature stored in a trusted third party such as the signature log management device 9 cannot be controlled by the signer himself, the signature log corresponding to this signature can be regarded as reliable.
[0108] Further, a signature published by a newspaper, a broadcast, or the like at a certain time before the signature verification by the signature verifier is performed, for example, immediately after being generated by the signature, and known by an unspecified number of people is also included. The signature log corresponding to this signature can be considered reliable, as it is very difficult for the signer to assume that the signature did not exist after that point and cannot be controlled by the signer himself.
[0109] If another non-interested purchaser or the like owns the signature (for example, as a signature log), it can be regarded as a reliable signature log as well.
[0110] Furthermore, if it can be confirmed that the signature log is consistent with the signature log immediately before these trusted signature logs, that is, the chain is maintained correctly, the signature log immediately before is also regarded as a trusted signature log. be able to. Because, in the present invention, since the signature log contains the hash value of the previous message or signature, a reliable signature can be obtained even if the digital signature itself is easily forged due to the disclosure of the private key or the like. This is because it is very difficult to forge the previous signature log so that it matches the hash value contained in the log. By repeatedly applying this procedure, we could start with a trusted signature log and go back one step at a time, that is, in the direction of the earlier signature log, making sure that the chain was maintained. The signature log can be considered a trusted part of the submitted signature log list.
[0111] In the present embodiment, when the digital signature side device 1 generates a digital signature, the previous data P including the previous signature target message, the hash value of the signature data, and the like.<sub>i</sub>However, in addition to the previous data, other data may be included in the signature generation.
[0112] For example, the public key certificate 2233 to be transmitted to the purchaser-side device 3 or a hash value thereof may be included. This has the advantage that when the digital signature generates the digital signature, it is easy to show that the public key certificate 2233 did exist. This is because the chain is formed with the public key certificate 2233 included and saved as a signature log, so the public key certificate part was later tampered with and did not exist. Because it is very difficult to do. As a result, even if the public key certificate can be forged in the future due to the disclosure of the private key of the certificate authority that issues the public key certificate, the public key certificate 2233 will not be forged. It becomes easier to show that there is no such thing.
[0113] Similarly, in order to be able to indicate that the data at the time when the digital signature was generated existed in the future, the data should be included in addition to the previous data when the digital signature is generated. can do. In this case, in order to enable signature verification, a message or signature is sent to the purchaser side device, such as the data or data obtained by transforming the data into a form required for signature verification (for example, a hash value of the data). Send with data etc.
[0114] In the present embodiment as well, as in the first embodiment described above, the signature log table 2234 may be set in the external storage device 13 included in the computer 21 in addition to the EEPROM 223.
[0115] Instead of setting the signature log table 2234 in the EEPROM 223, as described above, the signature log management device 9 that manages the signature log table may be provided for each digital signer side device 1.
[0116] The signature log management device 9 may be constructed on the same computer as the digital signature verifier side device 5 as in the first embodiment described above.
[0117] Similar to the first embodiment, data unique to each IC card (such as a serial number) is used to generate data for guaranteeing that the signature was generated by the IC card. You may decide.
[0118] When the signature log management device 9 is provided, prior to registering the signature log in the signature log list, the signature log management device 9 has S11207 and S11208 (third-stage signature verification) of the flow shown in FIG. And the signature of the signature log only if the previous data contained in the signature log matches the hash value and digital signature of the message contained in the latest signature log data registered in the signature log list. You may allow registration in the log list. In this case, it is also possible to omit S11207 and S11209 (third-stage signature verification) of the flow shown in FIG. 8 in the digital signature verifier side device 5.
[0119] Similar to the first embodiment, a plurality of signature logs may be collectively registered in the signature log list managed by the signature log management device 9. In this case, a message was created to the effect that the signature was registered in the signature log list, and a signature was generated for this message, and the signature was registered in the signature log list. It may reflect the facts.
[0120] Next, in the first embodiment described above, a third embodiment in which the validity / invalidity of the digital signature can be determined from the time information by including the time information in the digital signature will be described.
[0121] This system has a configuration in which a time stamp issuing device 8 for issuing a time stamp for a digital signature sent from the digital signature side device 1 is added to the system of the first embodiment shown in FIG. It becomes.
[0122] The schematic configuration of the time stamp issuing device 8 is the same as the configuration shown in FIG.
[0123] The external storage device 13 includes a time stamp issuing PG (program) 831 for encrypting the digital signature and time data sent from the digital signer side device 1 to generate a time stamp, and a time stamp generation. The private key 832 used in this case and the public key certificate 833 including the public key paired with the private key 832 are stored. These are loaded on RAM 12 and embodied by CPU 11 as a process called time stamp issuance processing unit 811.
[0124] With reference to FIG. 10, the operation when the purchaser-side device 3 obtains the digitally signed message from the digital signer-side device 1 will be described.
[0125] The digital signer side device 1 executes the processes of S6101 to S6103 shown in FIG. 4 (S15101). The signed message creation processing unit 111 transmits the digital signature sent from the signature generation processing unit 2211 to the time stamp issuing device 8 to request the issuance of the time stamp (S15102). When the signed message creation processing unit 111 receives the time stamp from the time stamp issuing device 8 (S15103), the signed message creation processing unit 111 adds the time stamp to the message to be sent and creates a digitally signed message. The purchaser who made the transmission request by attaching the public key certificate 2233 sent with the digital signature from the signature generation processing unit 2211 and the public key certificate 833 sent with the time stamp from the time stamp issuing device 8. It is transmitted to the side device 3 (S15104).
[0126] In the time stamp issuing device 8, the time stamp issuing processing unit 811 generates a time stamp when a digital signature is sent from the digital signature side device 1 (S15201). Specifically, the digital signature sent from the device 1 on the digital signer side and the time data indicating the reception time of the digital signature are encrypted using the private key 832 stored in the external storage device 83. To generate a time stamp. The time stamp issuing processing unit 811 attaches the public key certificate 833 stored in the external storage device 83 to the generated time stamp, and transmits the generated time stamp to the digital signer side device 1 that has transmitted the digital signature (S15202). ..
[0127] The purchaser-side device 3 executes the processes S6001 to S6002 shown in FIG. 4 to acquire a digitally signed message (S15001). Next, the signed message acquisition processing unit 311 uses the time stamp included in the received digitally signed message as the public key of the public key certificate 821 attached to the message (public key of the time stamp issuing device 8). A digital signature is obtained by decoding using (S15002). The processing of S6004 to S6006 is executed to verify the digital signature (S15003).
[0128] Using FIG. 11, the operation when the purchaser-side device 3 requests the digital signature-side device 5 to verify the digitally signed message obtained from the digital signature-side device 1 will be described. ..
[0129] In the present embodiment, the digital signer who is the user of the device 1 on the digital signer side may have the private key 2232 that he / she keeps secretly exposed and illegally obtained by a third party. If so, the date and time of exposure shall be specified and the digital signature verifier shall be contacted promptly. Then, the digital signature verifier associates the date and time notified by the digital signature with the address of the digital signature side device 1 used by the digital signer, and stores the digital signature verifier in the external storage device 53 of the digital signature verifier side device 5. It will be stored.
[0130] The verification request processing unit 312 executes the processes of S7001 to S7003 in the flow shown in FIG. 5, and obtains the verification result from the digital signature verifier side device 5 (S16001).
[0131] In the digital signature verification side device 5, when the signature verification processing unit 511 receives the verification request for the digitally signed message from the purchaser side device 3, the time included in the digitally signed message sent together with the request. The time data and the digital signature are obtained by decrypting the stamp using the public key of the public key certificate 821 (public key of the time stamp issuing device 8) attached to the digitally signed message (S16101).
[0132] The signature verification processing unit 511 examines the external storage device 53, and sets the exposure date and time of the private key 2232 for the digital signer side device 1 specified by the address attached to the digitally signed message. Check if it is (S16102). If the exposure date and time is set, the process proceeds to S16103, and if it is not set, the process proceeds to S16105 to execute the processes S7101 to S7109 shown in FIG.
[0133] In S16103, the signature verification processing unit 511 examines whether or not the date and time indicated by the time data obtained in S16101 is newer than the exposure time set in the external storage device 53 (S16103).
[0134] If it is new, it is determined that the digitally signed message to be verified is invalid, and the result is digitally specified by the purchaser side device 3 that sent the verification request and the address attached to the digitally signed message. Send to device 1 on the signer side (S16104). If it is not new, proceed to S16105 and execute the processes of S7101 to S7109 shown in FIG.
[0135] In the digital signature side device 1, the verification request processing unit 112 executes the processes of S7201 to S7204 shown in FIG. 5 (S16201).
Next, when FIG. 11 is used, when the digital signature side device 1 requests the digital signature verifier side device 5 to verify the digitally signed message generated by the own digital signature side device 1. The operation of is described.
[0137] The processing of the digital signature side device 1 is the same as the processing of S8001 to S8002 shown in FIG.
[0138] In the digital signature verification side device 5, when the signature verification processing unit 511 receives the verification request of the digitally signed message from the digital signer side device 1, the purchaser specified by the address sent together with the request. Digital signer who sent the verification request Requests the side device 3 to send a digitally signed message with the address of the side device 1, and waits for the message to be sent. After that, the processes of S16101 to S16105 shown in FIG. 11 are executed.
[0139] The processing of the purchaser-side device 3 is the same as the processing of S8201 to S8203 shown in FIG.
[0140] According to the present embodiment, the digital signature verifier side device 3 uses the public key of the time stamp issuing station side device 8 to decode the time stamp included in the digitally signed message to be verified and digitally. Get signature and time data. By checking whether or not the date and time indicated by the time data has passed the exposure date and time notified by the digital signature generator, it is possible to check the validity / invalidity of the digital signature prior to the verification of the digital signature.
[0141] In the above embodiment, the digital signature side device 1 may intermittently (for example, once every m times) request the issuance of the time stamp. To determine whether the digital signature is valid or invalid based on the exposure date and time notified by the digital signature generator for the digitally signed message without the time stamp, the following procedure may be performed.
[0142] When the digital signature side device 1 transmits the digital signature to the time stamp issuing device 8 and requests the time stamp issuance, the time sent from the time stamp issuing device 8 is as shown in FIG. The stamp is included in the signature log 2235 of the digital signature that is the target of the stamp and registered in the signature log table 2234. The signature log table 2234 is registered in chronological order.
[0143] The digital signature verifier side device 3 is a signature log registered before the signature log corresponding to the digitally signed message to be verified in the signature log table 2234, and a time stamp is recorded. The signature log is detected, the time stamp is decrypted, and time data is obtained. Since the registration to the signature log table 2234 is performed in chronological order, the digitally signed message to be verified is generated at least after the date and time indicated by the decrypted time data. Therefore, if the exposure date and time notified by the digital signer is earlier than the date and time indicated by the decrypted time data, the digitally signed message to be verified is determined to be invalid.
[0144] Further, in the second embodiment, it is also possible to determine the validity / invalidity of the digital signature by the time stamp. It is also possible to determine the validity / invalidity of the digital signature by the time stamp without combining it with the first embodiment or the second embodiment.
[0145] Unlike each of the above embodiments, the message itself may be included in the signature log 2235 when the storage device for storing the signature log table 2234 has a sufficient capacity.
[0146] Unlike each of the above embodiments, all the processes to be performed by the digital signature side device 1 may be performed in the computer 21.
[0147] In the present invention, unlike each of the above embodiments, a digital signature, a message (in addition to the previous data in the second embodiment), and a public key paired with a private key owned by the digital signer. Various signature methods can be applied that can authenticate whether or not the digital signature is made for the message.
[Effect of the Invention] As described above, according to the present invention, it is possible to distinguish between a digital signature made by the digital signature generator itself and a digital signature made by a third party impersonating the digital signature generator. Digital signature technology can be provided.
BRIEF DESCRIPTION OF THE DRAWINGS [Fig. 1] Fig. 1 is a schematic view of a system to which the first embodiment of the present invention is applied.
FIG. 2 is a schematic configuration diagram of a digital signature side device 1, a purchaser side device 3, a digital signature verifier side device 5, an intermediary side device 7, and a time stamp issuing device 8 shown in FIG.
FIG. 3 is a schematic configuration diagram of the IC card 22 shown in FIG.
FIG. 4 is a flow chart for explaining an operation when the purchaser-side device 3 obtains a digitally signed message from the digital signer-side device 1 in the first embodiment of the present invention.
FIG. 5: In the first embodiment of the present invention, when the purchaser-side device 3 requests the digital signature-side device 5 to verify the digitally signed message obtained from the digital signature-side device 1. It is a flow chart for demonstrating operation.
FIG. 6 In the first embodiment of the present invention, the digital signature side device 1 requests the digital signature verifier side device 5 to verify the digitally signed message generated by the own digital signature side device 1. It is a flow chart for demonstrating the operation at the time.
FIG. 7 is a diagram for explaining the structure of data stored in the signature log table 2234 in the second embodiment of the present invention.
FIG. 8: In the second embodiment of the present invention, when the purchaser-side device 3 requests the digital signature-side device 5 to verify the digitally signed message obtained from the digital signature-side device 1. It is a flow chart for demonstrating operation.
FIG. 9: In the second embodiment of the present invention, the digital signature side device 1 requests the digital signature verifier side device 5 to verify the digitally signed message generated by the own digital signature side device 1. It is a flow chart for demonstrating the operation at the time.
FIG. 10 is a flow chart for explaining an operation when the purchaser-side device 3 obtains a digitally signed message from the digital signer-side device 1 in the third embodiment of the present invention.
FIG. 11: In the third embodiment of the present invention, when the purchaser-side device 3 requests the digital signature-side device 5 to verify the digitally signed message obtained from the digital signature-side device 1. It is a flow chart for demonstrating operation.
FIG. 12 is a diagram for explaining the structure of data stored in the signature log table 2234 in a modified example of the third embodiment of the present invention.
[Explanation of codes] 1 ... Digital signature side device 3 ... Purchaser side device 5 ... Digital signature verifier side device 7 ... Mediator side device 8 ... Time stamp issuing device 9. .. Signature Log Management Device 11,31,51,81,221 ... CPU12,32,52,82,222 ... RAM13,33,53,83 ... External Storage Device 14,34,54,84 ... Read Device 15,35,55,85 ... Storage medium 16,36,56,86 ... Input device 17,37,57,87 ... Display device 18,38,58,88 ... Communication device 19 ... IC card connection device 20,40,60,90 ... Interface 21,41,61,91 ... Electronic computer 22 ... IC card 111 ... Signed message creation processing request unit 112,312 .. .Verification request processing unit 131 ... Signed message creation program 132,332 ... Verification request program 223 ... EEPROM 224 ... I / O 311 ... Signed message acquisition processing unit 331 ... Signed message acquisition program 511 ... Signature verification processing unit 531 ... Signature verification program 811 ... Time stamp issuance processing unit 831 ... Time stamp issuing program 832,2232 ... Private key 833,2233 ... Public key certificate 2211 ... Signature generation processing unit 2231 ... Signature generator 2234 ... Signature log table 2235 ... Signature log
Every citation, both waysCites: the store holds 5 of 6
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US11888990B2 | Cited by | United States of America | Search report |
| US2021281423A1 | Cited by | United States of America | Search report |
| JP11039219A | Cites | Japan | – |
| JP10327147A | Cites | Japan | – |
| JP2001331105A | Cites | Japan | – |
| JP2001265217A | Cites | Japan | – |
| JP04227154A | Cites | Japan | – |
| 松本勉、岩村充、佐々木良一、松木武,暗号ブレイク対応電子署名アリバイ実現機構(その1),情報処理学会研究報告,社団法人情報処理学会,2000年 3月22日,Vol.2000 No.30,p.13-17 | Non-patent | – | – |
| 洲崎誠一、宮崎邦彦、宝木和夫、松本勉,暗号ブレイク対応電子署名アリバイ実現機構(その2),情報処理学会研究報告,社団法人情報処理学会,2000年 3月22日,Vol.2000 No.30,p.19-24 | Non-patent | – | – |
27 members in 5 offices
Priority claims10
| Document | Office | Kind | Date |
|---|---|---|---|
| 1999301216 | Japan | – | |
| 30121699 | Japan | A | |
| 2000081712 | Japan | A | |
| 2000081712 | Japan | – | |
| 2000313123 | Japan | A | |
| 1999301216 | – | – | – |
| 2000200081712 | – | – | – |
| JP19990301216 | – | – | – |
| JP20000081712 | – | – | – |
| JP20000313123 | – | – | – |
Members27
| Document | Office | Kind | |
|---|---|---|---|
| EP1094424A2 | European Patent Office (EPO) | A2 | |
| JP2001331104A | Japan | A | |
| US2002023221A1 | United States of America | A1 | |
| EP1243999A2 | European Patent Office (EPO) | A2 | |
| AU3887901A | Australia | A | |
| JP2002335241A | Japan | A | |
| AU758676B2 | Australia | B2 | |
| JP2004040830A | Japan | A | |
| EP1396958A1 | European Patent Office (EPO) | A1 | |
| JP2004104750A | Japan | A | |
| EP1094424A3 | European Patent Office (EPO) | A3 | |
| US2004123107A1 | United States of America | A1 | |
| US2006059357A1 | United States of America | A1 | |
| SG120979A1 | Singapore | A1 | |
| EP1243999A3 | European Patent Office (EPO) | A3 | |
| US7134021B2 | United States of America | B2 | |
| JP3873603B2This record | Japan | B2 | |
| US7305558B1 | United States of America | B1 | |
| US2008098232A1 | United States of America | A1 | |
| JP2008136247A | Japan | A | |
| US7441115B2 | United States of America | B2 | |
| JP4206674B2 | Japan | B2 | |
| US7694126B2 | United States of America | B2 | |
| US7770009B2 | United States of America | B2 | |
| JP4626136B2 | Japan | B2 | |
| JP4853479B2 | Japan | B2 | |
| EP1243999B1 | European Patent Office (EPO) | B1 |
12 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written notification of patent or utility model registrationJAPANESE INTERMEDIATE CODE: R151R151 | R151 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Notification of change of attorneyJAPANESE INTERMEDIATE CODE: A7421RD01 | RD01 |
Numbers
- Publication
- 3873603
- Publication, DOCDB
- 3873603
- Publication, EPODOC
- JP3873603B
- Application
- 313123
- Application, DOCDB
- 2000313123
- Application, EPODOC
- JP20000313123
Titles2
- Japanese
- ディジタル署名方法および装置
- English
- Digital signature method and equipment
Classification
- IPC, 2
- G09C1 00
- H04L9 32