KR101200331B1 - Digital Signing Method among Cross Domains - Google Patents

Abstract

PURPOSE: A digital signature method for cross domains is provided to reduce infrastructure costs of digital signature for whole society by eliminating high cost processes including plug-in manufacture and distribution. CONSTITUTION: Information in a verification server storing a validation key is transmitted to a signature request server which requests digital signature from an original text. A signature text which is generated by processing the original text or an encryption value as a signature key is transmitted to the verification server(S44). A verification completion page is received from the signing request server(S50). The signature key and the validation key are generated through a java script for generating the signature key and the validation key which are formed on a signature key publication page provided from the validation server. The validation key is stored in the verification server by a user's browser. [Reference numerals] (100) Issuing domain; (200) User browser; (300) Service domain; (S10) Issuing page request; (S12) Issuing page providing; (S14) Generation of a signature key and a validation key; (S16) Validation key transmission; (S18) Validation key transmission; (S20) Informing completion of validation key storing; (S22) Signature key storing; (S30) Access to a service domain which needs a signature; (S32) Issuing domain input page; (S34) Issuing domain input or selection; (S36) Original text HASH generation; (S38) Transmission of validation URL redirection; (S40) Providing of a signature page; (S42) Signature key extraction and signature; (S44) Signature text transfer; (S46) Signature text verification; (S48) Verification results transfer by calling an URL reply; (S50) Validation completion page transfer

Description

Digital Signing Method among Cross Domains

The present invention relates to a cross-domain digital signature method. In particular, a web storage supported by HTML5 is used to generate, store, and distribute keys for digital signatures without the help of a separate plug-in program. It relates to a cross-domain digital signature method that enables a signature and verification using a key.

As is well known, until Web storage was supported, browsers had limited access to the computer's storage, typically the hard disk. In the past, browsers could access Active X or Java to access (read / write) the computer's storage. The help of a plug-in program using such a technique was needed.

The same problem has been applied to the field of digital signatures. In order to perform digital signatures in various browsers, a separate plug-in program is required for each browser platform. However, the installation of such a plug-in program not only worsens the user's web accessibility, but the plug-in program becomes a main distribution route of malicious code.

In addition, from the standpoint of the institutions that require digital signatures, the cost of producing and distributing their respective plug-in programs is enormous, which increases the cost of the entire digital signature infrastructure.

The present invention has been made to solve the above-mentioned problems, using a web storage supported by HTML5 to perform the generation, storage and distribution of keys for electronic signatures without the help of a separate plug-in program, and thus generated By signing and validating with keys, you can improve users' web accessibility and reduce the cost of the entire digital signature infrastructure by eliminating expensive operations such as plug-in creation and distribution. The purpose of the present invention is to provide a cross-domain digital signature method that can prevent various malicious codes from being introduced into a user's computer during the porting of an in-program.

Cross-domain digital signature method according to an aspect of the present invention for achieving the above object is a user browser of a user terminal equipped with a user browser for supporting a web storage to store a signature key for the electronic signature in the web storage Transmitting information of the verification server, in which the verification key is stored, to a signature request server requesting an electronic signature for the original text; When the original text to be digitally signed or an encryption value obtained by processing the original text with an encryption algorithm is received from the verification server, the signature text generated by processing the original text or the encryption value as the signature key is transmitted to the verification server. And receiving the verification completion page from the signature request server.

 In the above configuration, the signature key and the verification key are generated through a signature key and a verification key generation javascript implemented in a signature key issuing page provided by the verification server, and the verification key is verified by the user browser. It is characterized by being delivered to the server and stored.

Cross-domain digital signature method according to another aspect of the present invention is performed by the signature request server for requesting the digital signature for the original text, the information of the verification server that stores the verification key from the user browser mounted on the user terminal Receiving a step; The user is generated by generating the original text requiring the electronic signature, and redirecting the original text or the original URL to the verification URL of the verification server to receive the encryption value and the verification result obtained by the encryption algorithm. And transmitting the verification completion page including the verification result to the user browser when receiving the verification result from the verification server.

In the above configuration, the signature key and the verification key are generated through a signature key and a verification key generation javascript implemented in a signature key issuing page provided by the verification server, and the verification key is verified by the user browser. It is characterized by being delivered to the server and stored.

According to another aspect of the present invention, there is provided a cross-domain digital signature method, comprising: accessing a signature request server by a user browser of a user terminal equipped with a user browser storing a signature key for digital signature in a web storage; Receiving, by the signature request server, information of a verification server storing a verification key from the user browser; Generating, by the signature request server, original text that requires an electronic signature and processing the original text or the original text by an encryption algorithm to generate an encryption value obtained; Redirecting, by the signature request server, the original text or the encrypted URL and its reply URL information to receive the verification result to the verification URL of the verification server and transmitting the same to the user browser; Requesting, by the verification server, an electronic signature by transferring a signature page including the encryption value to the user browser; Transmitting, by the user browser, the signature text generated by processing the original text or the encryption value with the signature key to the verification server; After the verification server verifies the signature text by the verification key and the encryption value, redirects the verification result to the reply URL and transmits the verification result to the user browser, and the signature request server verifies the verification text according to the verification result. And sending a completion page to the user browser.

In the above-described configuration, the signature key and the verification key are generated through a signature key and a verification key generation javascript implemented in a signature key issuing page provided by the verification server, and then the signature key is stored in the web repository. The verification key is transmitted to the verification server by the user browser and stored.

According to still another feature of the present invention, there is provided a computer-readable recording medium in which a program for executing any of the above-described methods is stored.

According to the cross-domain digital signature method of the present invention, using a web storage supported by HTML5, the generation, storage and distribution of keys for digital signatures are performed without the help of a separate plug-in program, and the generated keys By signing and validating, you can improve users' web accessibility and eliminate costly tasks such as plug-in creation and distribution, reducing the cost of the entire digital signature infrastructure. It is possible to prevent the introduction of various malicious code on the user's computer during the porting process.

1 is a sequence chart for explaining the cross-domain digital signature method of the present invention.

Hereinafter, with reference to the accompanying drawings will be described in detail a preferred embodiment of the cross-domain digital signature method of the present invention.

1 is a sequence chart for explaining a cross-domain digital signature method of the present invention. Before describing, HTML5, which is the basis of the present invention, will be described, and the terms used in the present invention will be roughly defined.

As is well known, HyperText Markup Language (HTML) is a type of programming language that we use to lay out the content of web pages we see, to add colors or images, to link other web pages, etc. Internet Explorer, Firefox Or it can be implemented with a browser that lets you view web documents on the Internet, such as Chrome. In other words, the browser sees the tag and changes its appearance to fit the user.

On the other hand, as the Internet has developed, it is required to display multimedia rather than simply displaying text or pictures. As a result, various developers have not agreed upon each other without agreement through plug-in technology or Microsoft ActiveX technology. We have developed a program that can show multimedia. However, this situation has caused the multimedia to appear in some browsers and not in some browsers, and each company is making great efforts to solve the situation.

Against this backdrop, HTML5 is being standardized as a new version of the language for representing web pages. Its main features are the video and audio element functions that define video and audio on web pages, and the website information is stored locally. And local storage, which provides a way to read back later.

The function of the local storage is similar to the existing cookie, but it is designed to handle a larger and larger amount of information. Currently, the browser supporting HTML5 is Microsoft Internet Explorer 8.0 (IE 8.0) or higher. And Safari 6.0 or later.

In the present invention, the web storage (generally implemented as a hard disk of a PC) refers to a web storage or a web database provided by the HTML5 standard. Have. Java script is a scripting language built into web browsers. The issuing domain 100 refers to a domain of a site that is accessed in the process of generating and storing data for digital signature, which may be any domain but has a social credibility, such as a domain of a site operated by a bank. Would be desirable. On the other hand, a digital signature requires the generation of a signature key (also called a 'private key') and a verification key (also called a 'public key'), of which only the signature key or both the signature key and the verification key can be stored. have.

For reference, when the signature key is X, the verification key is Y, the signature function is f, the verification function is g, and the original text to be signed, for example, transaction or transfer history, is M, The signature text S becomes S = f (M, X). Verification is the result of g (M, S, Y), which can be either true or false.

On the other hand, only the issuing domain 100 has access to the data created and stored by the user, which means that only the domain that created the data can access the data when defining the web repository in HTML5. This is because the standard is set.

The service domain 300 refers to the domain of all service providing sites other than the issuing domain 100 as a domain for providing a service, and may be a domain of various portals, online shopping malls, or financial institution sites. will be. According to the foregoing description, the service domain 300 does not have a right to access data generated and stored in the issuing domain 100. However, the issuing domain 100 itself may be a service domain.

Returning to FIG. 1, in a state where a browser supporting a HTML5 standard (hereinafter referred to as a 'user browser') 200 is mounted on a user's computer, the user browser 200 accesses the issuing domain 100 and issues a signature key. The page is requested (step S10), and in response to the request, the issuing domain 100 provides the user browser 200 with a publishing page in a predetermined form (step S12).

By the way, the user who wants to issue the signing key visits an offline store of the issuing domain 100, for example, a bank branch, and the like, and registers the signing key as in the issuance of the certificate before the issuing page request in step S10. You can also be given a temporary password that will be used in the process of issuing a signature key.

In this case, when a user requests a signature key issuing after entering the temporary password on the issuing page, the issuing domain 100 checks whether the temporary password thus entered matches the temporary password that is granted and stored in the database. If it matches, the script implemented in the publish page. For example, a signature key and a verification key for verifying the signature key are generated through a Javascript for generating a signature key and a verification key implemented on an issuance page (step S14), and then a verification key is transmitted to the issuing domain 100 (step S16). )do. Here, the signature key may be randomly generated by a pseudo random number, or may be generated by being encrypted by the signature key password inputted by the user in the signature key password input box provided on the issue page.

Next, the issuing domain 100 matches the identification key of the user with the identification information of the corresponding user and stores it in the database operated by the user (S18), and then notifies the user browser 200 of the completion of the verification key storage (step S20). )do. As soon as the user browser 200 is notified of the completion of storing the verification key, the user browser 200 stores the signature key in a designated place of the web storage (step S22). In the figure, an "X" indicates that the current procedure has been completed, and generation and storage of the signature key and the verification key are completed by step S22 above.

In this state, the user's browser 200 accesses the service domain 300 requiring the electronic signature, for example, an online shopping mall site or a financial institution site (step S30), purchases an article or service, and then purchases the electronic signature for payment. If you want to do the Internet banking, for example, online account transfer service domain 300 provides the issuing domain input page to the user browser 200 for verification (step S32). Thereafter, the user browser 200 receives or selects information on the issuing domain from the user through the issuing domain input page (step S34) and delivers the information to the service domain 300, for example, through an input window provided on the input page. You can either manually enter the information for the issuing domain, such as "Kookmin Bank" or "http://www.kbstar.com", or select one from the list of issuing domains listed on the entry page.

Next, the service domain 300 encrypts the original text that needs to be signed, for example, transaction history or transfer history, using a hash function (step S36). The redirection URL information of the service domain) is redirected to the verification URL (Uniform Resource Locator) of the issuing domain 100 and transmitted to the user browser 200 (step S38).

In this case, the hash function is a computer encryption technique, also called a summary function or message digest function, and generates a fixed length pseudorandom number in a given text. The value generated by this is called a hash value.

In this regard, when data is exchanged through a communication line, the hash value of the data is calculated at both ends of the path, and the value of the sender and the receiver is compared to determine whether changes were made during data exchange. You can see how it works. Since the hash function contains an irreversible one-way function, the original text cannot be reproduced from the hash value, and it is extremely difficult to create other data having the same hash value. Here, the one-way function is also called a trap door function, and it is a function that is simple to obtain a result from a divisor but difficult to find a divisor from the result.

Next, the issuing domain 100 temporarily stores the reply URL information and the hash value received from the service domain 300, and then delivers the signature page including the hash value to the user browser 200 (step S40). Request a digital signature. In response, the user browser 200 extracts the signature key stored in the web store, performs the digital signature on the hash value (step S42), and then transfers the signature text generated thereby to the issuing domain 100 (step S44). In this process, as in the prior art, the digital signature may be performed only when the user preset digital signature password matches.

Next, the issuing domain 100, which has received the signature text from the user browser 200, verifies the signature text by using the verification key and hash value stored thereafter (step S46), and then, the verification result, for example. Information related to true or false is redirected to the reply URL, that is, the URL of the service domain 300, and transmitted to the user browser 200 (step S48). In this case, the verification contents in the issuing domain 100 may include, for example, whether or not the normal issuance expires.

Finally, the service domain 300 receiving the verification result transmits the verification completion page to the user browser 200 (step S50), thereby terminating the program.

The cross-domain digital signature method of the present invention is not limited to the above-described embodiments, and may be freely modified within the scope of the technical spirit of the present invention. For example, other financial information, for example, an account password or a security card serial number, may be used instead of the temporary password when verifying the present application in the aforementioned signature key issuing process.

In addition, the user browser 200 is described as being mounted on a PC, and the web storage is described as an example of a hard disk of a PC. However, if it is possible to perform the same function, the user browser is a smart phone or PDA (Personal Digital Assistance). It could be mounted on a portable telecommunications terminal, in which case the web storage could be internal or external flash memory.

On the other hand, when the signature key is stored in step S22, the verification key may be stored together to hide the responsibility of the future in the event of a future problem, as well as storing the signature key in step S22 is performed simultaneously with generating the signature key in step S14, That is, it may be performed before step S16.

Step S36 may be omitted. In this case, in step S38, the original text is redirected to the user browser 200 instead of the hash value, and the signature page transmitted to the user browser in step S40 includes the original text. The browser 200 may change the program by extracting the signature key stored in the web storage and performing the electronic signature on the original text.

Furthermore, in step S48, the issuing domain 100 may transmit the verification data, that is, the signature text and the verification key for verifying the verification data, when the verification result is transmitted, and the service domain 300 transmits the verification key to its own database. It can be stored in text and used to mask responsible material in the future. In addition, other encryption algorithms may be used instead of encryption by the hash function.

In the following claims, the term 'user terminal' is used as a generic term for a PC equipped with a user browser and a portable information communication terminal, and a verification server and a signature request server are each used at a site of a server and a service domain. Note that it is used as a general term for the built server. In addition, in the claims, an encryption value refers to a hash value encrypted by a hash function or a value encrypted by another encryption algorithm.

100: publishing domain, 200: user browser,
300: service domain

Claims (7)

Is performed by the user browser of the user terminal equipped with a user browser for supporting a web storage to store a signature key for digital signature in the web storage,
Transmitting information of a verification server, in which a verification key is stored, to a signature requesting server requesting an electronic signature for original text;
When the original text to be digitally signed or an encryption value obtained by processing the original text with an encryption algorithm is received from the verification server, the signature text generated by processing the original text or the encryption value as the signature key is transmitted to the verification server. Steps and
Cross-domain digital signature method comprising the step of receiving a verification complete page from the signature request server. The method of claim 1,
The signature key and the verification key are generated through a signature key and a verification key generation javascript implemented in a signature key issuing page provided by the verification server.
And the verification key is transmitted and stored by the user browser to a verification server. Performed by a signature request server requesting an electronic signature for the original text,
Receiving information of a verification server in which a verification key is stored, from a user browser mounted on the user terminal;
The user is generated by generating the original text requiring the electronic signature, and redirecting the original text or the original URL to the verification URL of the verification server to receive the encryption value and the verification result obtained by the encryption algorithm. Sending to the browser, and
And when the verification result is received from the verification server, delivering the verification completion page including the verification result to the user browser. The method of claim 1,
The signature key and the verification key are generated through a signature key and a verification key generation javascript implemented in a signature key issuing page provided by the verification server.
And the verification key is transmitted and stored by the user browser to a verification server. Accessing a signature request server by the user browser of a user terminal equipped with a user browser storing a signature key for electronic signature in a web storage;
Receiving, by the signature request server, information of a verification server storing a verification key from the user browser;
Generating, by the signature request server, original text that requires an electronic signature and processing the original text or the original text by an encryption algorithm to generate an encryption value obtained;
Redirecting, by the signature request server, the original text or the encrypted URL and its reply URL information to receive the verification result to the verification URL of the verification server and transmitting the same to the user browser;
Requesting, by the verification server, an electronic signature by transferring a signature page including the encryption value to the user browser;
Transmitting, by the user browser, the signature text generated by processing the original text or the encryption value with the signature key to the verification server;
After the verification server verifies the signature text by the verification key and the encryption value, redirects the verification result to the reply URL and sends the verification text to the user browser; and
And sending, by the signature request server, a verification completion page according to the verification result to the user browser. The method of claim 5, wherein
After the signature key and the verification key are generated through a signature key and a verification key generation javascript implemented in a signature key issuing page provided by the verification server, the signature key is stored in the web storage, and the verification key is Cross-domain digital signature method characterized in that the delivered to the verification server by the user browser and stored. A computer-readable recording medium having a program for executing the method of any one of claims 1 to 6.

Images