KR100760028B1 - Long-term verification method and system for certificate of the electronic signature - Google Patents

Abstract

The present invention relates to a long-term verification method for a certificate capable of reliably verifying whether a digital signature was generated in a valid state of a certificate by enabling the verification of the certificate status at the time of the digital signature. In the long-term verification method of the present invention, in the long-term verification server S (11): register the certificate information for the long-term verification, and receives the status confirmation information for the registered certificate from the certification authority server 18, the electronic signature A data storage step of generating signed data, extending the validity of the data by adding a timestamp token issued from the TSA server 19 to the data, and storing the signed data; In the client system 20: access the long-term verification server S (11) to provide the certificate information and time information together to request data, and when receiving the data from the long-term verification server S (11), validity of the data itself After verification, a verification step of verifying the validity of the certificate to be verified through the certificate status check information included in the data.

Digital signature, certificate, long-term verification, certification authority, time stamp

Description

Long-term verification method and system for certificate of the electronic signature}

1 is a view for explaining a conventional verification method.

2 is a system configuration for performing long-term verification according to the present invention.

3 is a flow chart of long-term verification according to the present invention.

4 is a flow chart of verification for the signed data itself in FIG.

<Description of the symbols for the main parts of the drawings>

10. Digital Signature Certificate Long-term Verification System

11. Long-term verification server 12. Certificate registration module

13. Module for issuing certificate status check

14. Digital Signature Module 15. Timestamp Token Issuance Module

16. Storage management module 17. Server-side data transmission / reception module

18. Certificate Authority Server 19. TSA Server

20. Client system 21. Client-side data transmission / reception module

22. Certificate Validation Module

The present invention relates to a long-term verification of the digital signature certificate, and more specifically, to verify the status of the certificate at the time of the digital signature certificate that can verify whether the digital signature generated at a specific point in time in the past was generated in the valid state of the certificate It relates to a long-term verification method and system.

As real-life activities are incorporated from off-line to on-line, commodities such as banks, securities, and shopping are traded electronically, and the digital signatures used in these transactions are becoming legal. On the other hand, the authenticity of the electronic data is guaranteed by the electronic signature, but there is a case where there is no way to check the validity or attribution after the e-signed data is generated.

FIG. 1 illustrates a method for verifying digitally signed data that is generally performed based on a public key infrastructure (PKI). In order, the digitally signed electronic document 1 is signed by the signature certificate 2 which has previously performed the digital signature. If the signature verification is normal, the certificate verification is executed through the certificate chain (5) up to the signature certificate (2), the certificate of the issuer (3) and the certificate of the highest authority (4). In the process, each certificate (2, 3, 4) is issued from the Certificate Authority (6) that issued the certificate, Online Certificate Status Protocol (OCSP), Certificate Revocation List (CRL), or ARL ( Certificate Revocation List (Certificate Revocation List) is sent to verify its validity. The certificate (4) of the last top authority is confirmed by the hash value of the certificate or the public key. If all of these procedures are successful, the electronic document 1 is validated at the time of verification.

The problem here is that the certification authority 6 may not be able to provide the status check information of the certificate for a specific day in the past. The certificate issued by the certification authority 6 has a validity period already set, and the certificate chain 5 receives the OCSP, CRL or ARL information provided by the certification authority 6 and performs verification. Since the certification authority 6 cannot confirm the passed certificate, it becomes impossible to verify the digitally signed electronic document. Because of this, even though the data was valid at the time of the digital signature, it was later asserted that the signing party was `` not responsible for the electronic transaction because it lost its private key and certificate before the date of signature and reported it to the certification authority (6). '' Even if it is malicious, there is no proof way to solve it. Fundamentally, the verification itself does not check the certificate at the time of the digital signature, but it has no choice but to check the certificate status at the time of verification.

It can be considered to simply issue and use a certificate having a sufficient validity period by the certification authority 6, but it is practically impossible to increase the validity period of the certificate indefinitely due to problems such as the development of the attack technique of the encryption algorithm. Alternatively, powerful and complex key algorithms and key lengths can be used, but there are problems such as increased computation time and memory usage. Therefore, there is a need for a technical solution to the long-term verification of digital signatures.

The Internet Engineering Task Force (IETF) proposes standardization through RFC3126 for long-term verification of digital signatures. This approach includes Time Stamp Token technology and technology to maintain certificate verification information. If outlined as follows.

The creator of the digital signature delivers the electronic document to the Trusted Service Provider (TSP) for long-term storage of the digital signature document. After verifying the signature of the electronic document, the TSP obtains a timestamp token for the electronic document from a time stamping authority (TSA). The timestamp token contains the hash value and time source of the electronic document, and is attached to the TSA's certificate signature. As a result, the validity period of the electronic document can be increased by the validity period of the TSA certificate. This expiration date can be renewed by creating a new timestamp token before the TSA's certificate expires. IETF RFC3126 provides useful methods for the long-term verification of digital signatures by suggesting how to properly extend the validity period of electronic documents.

According to this method, validity of the digital signature is possible if the certificate issued by the certification authority is within the validity period of the TSA certificate even if the validity period expires or is revoked within the validity period. However, there is a limit that the verification itself does not check the certificate at the time of digital signature, but remains at the degree of checking the certificate status at the time of verification.

Technically, there is a problem in that a large amount of data is allocated to the processing itself when managing a large amount of data, since a timestamp token must be separately issued and stored from the TSA for all digitally signed data. In addition, when the signed data is transmitted to the outside, there is a problem that the processed data cannot be processed. In this case, there is a possibility that the verification result for the same data is normal on the one hand but verification error on the other hand.

Another problem is that IETF RFC3126 is only applicable to data signed in the recommended specific format (so-called "SignedData"). For example, there may be a case where a signature is generated and stored in the hash value of the data and then stored separately, and the associated certificate is separately stored.In this case, the signature is verified with the public key of the certificate and the certificate is verified. There is a problem that IETF RFC3126 does not support data signed in this way.

The present invention has been made to recognize and solve the problems of the prior art. According to the present invention, it is possible to check the status of a certificate at the time of performing an electronic signature, so that a reliable verification of the validity of the digitally signed data can be made at any point in time regardless of expiration, revocation, or suspension of the validity period of the certificate. It is intended to provide a way to do this.

The long-term verification method according to the present invention includes a data storage step of the long-term verification server and a verification step of the client system.

In the long-term verification server: Register the certificate information for the long-term verification, receive the status confirmation information for the registered certificate from the certification authority server, performs the digital signature on it to generate the signed data, TSA to this data By adding the timestamp token issued from the server, the verifiable period of data is extended to store the data.

And in the client system: access the long-term verification server to provide the certificate information and time information together to request data, and when receiving the data from the long-term verification server, after validating the data itself, the certificate included in the data Verification step to verify the validity of the certificate at the time requested by the status check information.

According to the present invention, it is possible to check the status of the certificate at the time of performing the digital signature, and therefore, regardless of the reason for expiration of the validity period of the certificate, revocation or suspension of the certificate, etc. Reliable verification can be done.

Referring to Figure 2, the digital signature long-term verification system according to the present invention is denoted by 10. The long-term verification system 10 is a long term validation server (hereinafter referred to as 'LTVS') 11 that stores and manages data for long-term verification, and a client system 20 that requests and confirms the data. And a certification authority server 18 and a TSA server 19 for providing the LTVS 11 with the necessary information for long-term verification. The LTVS 11 and the client system 20 include function modules 12 to 17 and 21 to 22 to perform respective functions.

The LTVS 11 includes: a certificate registration module 12 for registering a certificate for long-term verification, and a certificate status check issuing module 13 for receiving status check information on the registered certificate from a certification authority server 18. ), A digital signature module 14 for generating signed data by performing digital signature on the received certificate status check information, and a timestamp from the TSA server 19 for a hash value of the generated signed data. A timestamp token issuance execution module 15 for receiving a token and adding it to signed data, a storage management module 16 for storing the signed data, and a request from a client system 20 and receiving the result. Server side data transmission and reception module 17 for transmitting.

On the other hand, the client system 20 is connected to the server-side data transmission and reception module 17, the client-side data transmission and reception module 21 for requesting the corresponding data by providing certificate information and time information, and the received signed data itself After verifying and verifying, the certificate validity verification module 22 for verifying and verifying the status of the certificate at a specific point of time required by performing the validity of the certificate to be verified through the certificate status check information included therein. do.

3 shows in one flow the information storage process 25 of the LTVS 11 and the verification process 26 of the client system 20.

First, the information storage process 25 of the LTVS 11 is as follows. The LTVS 11 registers certificate information for long term verification. Registration of the certificate information is made automatically or by the operation of the administrator, it is performed in the certificate registration module (12). The certificate information may be the certificate itself or the certificate status check information. Ultimately, the value parsed from the registered certificate information is certificate status check information.

The LTVS 11 receives status confirmation information about the registered certificate, for example, OCSP, CRL or ARL information from the certification authority server 18. Receipt of the certificate status check information is made every day, periodically, or at a particular point in time, if necessary, and is performed by the certificate status check issuing execution module 13.

The received certificate status confirmation information is received, and digital signature is performed on the information to generate signed data. The digital signature is made by the electronic signature module 14.

The timestamp token is issued from the TSA server 19 for the hash value of the generated signed data and added to the signed data. This is performed by the time stamp token issuing execution module 15. As a result, the data validity period is extended by the certificate validity period of the TSA. The time stamp is issued when the validity period of the signature certificate performed in the digital signature module 14 expires (extends) or the validity period expires (update) of the TSA's signature certificate that has already issued the timestamp token. The extension of the verifiable period in this way is in accordance with IETF RFC3126. However, other known methods may be possible.

The results performed in the above modules 13, 14 and 15 are stored and managed in the storage management module 16. The LTVS 11 includes, in addition to the above modules 12 to 16 in terms of configuration, a server-side data transmission / reception module 17 for receiving a request from the client system 20 and transmitting the result.

Next, the verification process 26 of the client system 20 is as follows. The client system 20 connects to the LTVS 11 and requests evidence for validity verification at a specific point in time in the past for the certificate that is the subject of the digital signature validation. Information to be delivered upon request includes certificate information and information about the specific time point to be verified. The certificate information may be a certificate itself, a certificate identifier, or certificate status check information.

Upon receiving the request of the client system 20, the server-side data transmission / reception module 17 retrieves the requested data from the storage management module 16 and transmits the requested data to the client system 20. Request and reception of data is made through the client-side data transmission and reception module 21.

After receiving the data, the client system 20 verifies the signed data itself, and then verifies the validity of the certificate at the time requested by the certificate status information included therein, that is, OCSP, CRL, or ARL. By doing so, it is possible to verify and verify the status of the certificate at a specific point in the past. This is done through the certificate validity check module 22.

Referring to FIG. 4, verification of the signed data itself is performed as follows. First, if the signed certificate is valid after reviewing the validity period of the signature certificate, the validity of the certificate to be verified is verified through OCSP, CRL or ARL included in the signed data. After that, the validity of the specific past time point of the certificate to be verified is verified again. Verification and validation of the timing information for the certificate does not matter in order. If the validity period of the signature certificate has elapsed, the timestamp token included in the signed data is extracted, the association with the signed data is verified using a one-way hash function, and the TSA certificate issuing the timestamp token. After reviewing the validity, the verification of the validity and time information of the certificate to be verified is performed.

According to the present invention, it is possible to check the status of a certificate at the time of performing an electronic signature, so that a reliable verification of the validity of the digitally signed data can be made at any point in time regardless of expiration, revocation, or suspension of the validity period of the certificate. It can be effective.

Claims (8)

delete In the long-term verification server 11: Register the certificate information for the long-term verification, receive the status confirmation information for the registered certificate from the certification authority server 18, and performs the digital signature to generate the signed data A data storage step of extending and validating the verifiable period of data by adding a time stamp token issued from the TSA server 19 to the data; In the client system 20: access the long-term verification server 11 to provide the certificate information and time information together to request data, and when receiving the data from the long-term verification server 11, the data itself is validated Later, a verification step of verifying the validity of the certificate at the time requested by the certificate status check information included in the data, The client system 20 validates the data itself by reviewing the validity period of the signature certificate, checking whether the signed certificate is valid, and if the validity period of the signature certificate has elapsed, the timestamp included in the signed data. And extracting the token and verifying the association with the signed data using a one-way hash function, and then examining the validity of the TSA's certificate that issued the timestamp token. The method of claim 2, The certificate registration in the long-term verification server (11) is a certificate itself, or the long-term verification method of the digital signature certificate, characterized in that the status confirmation information for the certificate. The method of claim 2, The long-term verification method of the digital signature certificate, characterized in that the IETF RFC3126 method is applied as a method for extending the validity of the data in the long-term verification server S (11). The method of claim 2, The long-term verification method of the digital signature certificate, characterized in that the data storage step in the long-term verification server S (11) is performed every day, periodically or at a specific point in time. The method of claim 2, The certificate information provided when the client system 20 requests data by accessing the long-term verification server S 11 is an electronic signature, which is a certificate itself or an identifier for identifying a certificate or status confirmation information for a certificate. Long-term verification method of certificate. Certificate registration module 12 for registering certificate information for long-term verification, certificate status confirmation issuing execution module 13 for receiving the status check information for the registered certificate from the certification authority server 18, and the reception The digital signature module 14 generates signed data by performing digital signature on the signed certificate status check information, and receives a timestamp token from the TSA server 19 for the hash value of the signed data. A timestamp token issuance execution module 15 to be added to the storage management module 16 for storing the signed data, and a server-side data transmission and reception module for receiving a request from the client system 20 and transmitting the result thereof ( A long term verification server 11 including 17); After accessing the server-side data transmission / reception module 17 and providing the certificate information and the timing information, the client-side data transmission / reception module 21 requesting the data and the validity of the received data itself are included and then included in the server-side data transmission / reception module 17. Characterized in that the client system 20 including a certificate validity check module 22 for verifying and verifying the certificate status at the time of the request by checking the validity of the certificate to be verified through the certificate status check information. Long-term verification system of digital signature certificate. The method of claim 7, wherein The token issuance execution module 15 is a long-term verification system of the digital signature certificate, characterized in that the module for performing the IETF RFC3126 method.

Images