Encryption authentication system
Abstract
[Task] To provide a cryptographic authentication method that can prevent theft of authentication information on the data transfer path and establish a cryptographic key property for a mock server or a mock client.
Solution.The client-side public encryption key is transmitted from the client to the server, and the server asks the client a question using the client-side public encryption key. Using the client-side public encryption key, the server-side public encryption key is also transmitted from the server to the client. Using the server-side public encryption key, the answer to the question is transmitted from the client to the server, and if the answer from the client is correct, the encryption key is established, and authentication is established between the server and the client. The server-side public encryption key may be sent in the form of a tally.
Term
Term ended
Projected expiry passed 14 May 2017, 9.4 years ago.
- Priority and filed
- Published
- Projected expiry
- Today
8 claims: 2 independent, 6 dependent
- 1【特許請求の範囲】 【請求項1】 クライアント側公開暗号キーをクライアントからサーバーに送信することと、 前記クライアント側公開暗号キーを用いて、前記サーバーから前記クライアントに質問を発することと、 前記クライアント側公開暗号キーを用いて、サーバー側公開暗号キーを前記サーバーから前記クライアントに送信することと、 前記サーバー側公開暗号キーを用いて、前記質問の回答を前記クライアントから前記サーバーに送信することと、及び前記クライアントからの前記回答が正しいと暗号キー、前記サーバーと前記クライアント間に認証を確立することとを具備する暗号認証方式。
- 2【請求項2】 クライアント側公開暗号キーをクライアントからサーバーに送信することと、 前記クライアント側公開暗号キーを用いて、前記サーバーから前記クライアントに質問を発することと、 前記クライアント側公開暗号キーを用いて、サーバー側公開暗号キーのための第1の割り符を前記サーバーから前記クライアントに送信することと、 受信される前記第1の割り符と保持している第2の割り符から前記サーバー側公開暗号キーを生成し、生成されたサーバー側公開暗号キーを用いて、前記質問の回答を前記クライアントから前記サーバーに送信することと、及び前記クライアントからの前記回答が正しいとき、前記サーバーと前記クライアント間に認証を確立することとを具備する暗号認証方式。
- 3【請求項3】 前記クライアントは、前記第1と第2の割り符と予め定められたアルゴリズムにより前記サーバー側公開暗号キーを生成する請求項2に記載の暗号認証方式。
- 4【請求項4】 前記サーバーは、前記クライアント側の前記第2の割り符に基づいて前記第1の割り符を動的に発生することを含む請求項2または3に記載の暗号認証方式。
- 5【請求項5】 認証確立後、その後の通信に使用される共通暗号暗号キーを前記サーバーから前記クライアントに送信することを具備する請求項1乃至4のいずれかに記載の暗号認証方式。
- 6【請求項6】 前記共通暗号暗号キーは、前記サーバーが動的に発生する請求項5に記載の暗号認証方式。
- 7【請求項7】 前記クライアント側公開暗号キーは、前記クライアントが動的に発生する請求項1乃至6のいずれかに記載の暗号認証方式。
- 8【請求項8】 前記サーバーには、複数の質問が用意されており、前記サーバーは動的に選択した少なくとも1つの質問を前記クライアントに送信する請求項1乃至7のいずれかに記載の暗号認証方式。
Independent claims8
135 paragraphs in 1 section, as filed
Description: TECHNICAL FIELD [Detailed description of the invention]
【0001】
[Technical field to which the invention belongs]
The present invention relates to the cryptographic authority between the server and the client, and particularly to the establishment of authentication between the client and the server.
【0002】
[Conventional technology]
Communication networks, as represented by the Internet and intranets, are showing rapid development. Along with this, new transaction forms such as electronic transaction encryption keys and electronic money are about to occur.
【0003】
The Internet is a network derived from DARPA in the United States, and uses TCP / IP as the protocol. As a feature, the bucket brigade method is used for data transfer. That is, each node relays the data packet toward the target terminal. Therefore, it is relatively easy to steal or falsify data packets at each of the nodes located between the source node and the destination node of the data.
【0004】
Intranets are basically open Internet technologies introduced into closed or partially closed networks.
【0005】
When a client accesses a server, the conventional basic authentication procedure performed to recognize which client the server is is described below with reference to FIG.
【0006】
In step S102, the client accesses the server. In step S104, the server requests the client for an identifier (ID) and an identifier guarantor (password). In step S106, the client sends the ID and password to the server. In step S108, the server determines if the combination of ID and password from the client is correct. If it is determined in step S108 that the combination of ID and password from the client is correct, in step S110, the server grants the client access. At the same time, the server understands who the client is. Here, the server is, for example, a bank, a host computer, a terminal computer, a personal computer, etc., and the client is, for example, a human being, a terminal computer, or the like.
【0007】
In the above method, the ID and password are used to authenticate the client. However, if the ID and password are stolen in the middle of the transmission route, there is no guarantee that correct authentication will be performed thereafter.
【0008】
In addition, simply encrypting the transmitted data does not make sense because it merely creates a new ID and password required for identification and steals the data on the data transfer path. That is, encryption is effective only when "data obtained by restoring encrypted data" is important. Encryption is meaningless when the encrypted data itself is important, as in the case of authentication. This is because what is needed to impersonate the party to the communication is not the decrypted content of the encrypted data, but the encrypted data itself. If you steal the encrypted data and send the encrypted data to the server, the authentication will be successful.
【0009】
In order to solve the above problems, various methods for establishing authentication between the client and the server to secure data communication have been proposed and will be described below.
【0010】
One method is an encryption method using a common encryption key represented by DES. In this case, it is an encryption method in which the same common encryption key is used for encryption and decryption, and is the most common encryption method. However, even with this method, if the common encryption key is stolen, there is no guarantee that the encryption key will be properly authenticated.
【0011】
Therefore, as a more secure cryptographic authentication method, a cryptographic method using a public cryptographic key and a private cryptographic key represented by RSA is used. Here, the public encryption key is an encryption key of the encryption key when encrypted, and the private encryption key is an encryption key used as the encryption key when the one encrypted by the public encryption key is decrypted. Obtaining a private encryption key from a public encryption key is difficult and more reliable than the DES method. However, it is still not enough when considering e-commerce.
【0012】
In this way, when performing the above-mentioned authentication on all networks such as the Internet and intranets, or on computer systems, if the information required for authentication is stolen on the data transfer path, that information can be used. It is possible to impersonate another person. In such a case, reliable authentication does not require an encryption key, which is the biggest bottleneck in conducting electronic commerce.
【0013】
[Problems to be Solved by the Invention]
The present invention has been made in view of the above circumstances. Therefore, an object of the present invention is to prevent theft of authentication information on a data transfer path, and to provide a cryptographic authentication method that has almost no effect on the establishment of authentication even if it is stolen. Another object of the present invention is to provide an encrypted authentication method capable of establishing security for a simulated server or simulated client in an open network or the like.
【0014】
[Means for solving problems]
In the cryptographic authentication method of the present invention, the client-side public encryption key is transmitted from the client to the server, and the server issues a question to the client using the client-side public encryption key. Using the client-side public encryption key, the server-side public encryption key is also transmitted from the server to the client. Using the server-side public encryption key, the answer to the question is transmitted from the client to the server, and if the answer from the client is correct, the encryption key is established, and authentication is established between the server and the client.
【0015】
Further, in the cryptographic authentication method of the present invention, the client-side public cryptographic key is transmitted from the client to the server. Using the client-side public encryption key, the server asks the client a question, and using the client-side public encryption key, a first tally for the server-side public encryption key is issued by the server. It is sent to the client. The client generates the server-side public encryption key from the first tally received and the second tally held, and uses the generated server-side public encryption key to answer the question. It is transmitted from the client to the server. When the answer from the client is correct, authentication is established between the server and the client.
【0016】
In the above cryptographic authentication method, the client generates the server-side public cryptographic key by the first and second tally and a predetermined algorithm.
【0017】
In the above cryptographic authentication method, the server dynamically generates the first tally based on the second tally on the client side.
【0018】
In the above-mentioned cryptographic authentication method, after the authentication is established, the common cryptographic encryption key is transmitted from the server to the client, and subsequent communication is performed using this common cryptographic key.
【0019】
In the above cryptographic authentication method, the server dynamically generates the common cryptographic encryption key.
【0020】
In the above cryptographic authentication method, the client dynamically generates the client-side public encryption key.
【0021】
In the above cryptographic authentication method, the server is prepared with a plurality of questions, and the server sends at least one dynamically selected question to the client.
【0022】
BEST MODE FOR CARRYING OUT THE INVENTION
The cryptographic authentication method according to the present invention will be described below with reference to the drawings.
【0023】
As described above, simply encrypting the data does not make sense because it merely creates a new ID and password required for identification and steals the data on the transfer path. Therefore, the cryptographic authentication method according to the first embodiment of the present invention is executed by the following procedure.
【0024】
When authentication should be established between the server and the client, in step S2, the client dynamically randomly generates a client-side public encryption key and sends it to the server. In step S4, the server asks the client a question using the client-side public encryption key. The "question" plays the same role as the ID and password described above. Therefore, the question may be a traditional ID and password.
【0025】
There is at least one question, and generally multiple questions. At least one of those questions will be asked. Of course, in this case, you can ask only one question. It is inconvenient for a human-operated client to have multiple questions, but for computers and the like, it is more secure to ask some of the multiple questions. Further, a dynamically determined number of questions may be asked from a plurality of questions. Security can be further enhanced if a dynamically determined number of dynamically selected questions are asked.
【0026】
In step S4, the server also sends the server-side public encryption key to the client.
【0027】
In step S6, the client sends the answer to the question to the server using the server-side public encryption key.
【0028】
If the answer to the question is correct, the client authentication is established, and in step S8, the server dynamically generates a common cryptographic key to be used for future communication, and uses the client-side public cryptographic key as the common cryptographic key. And send it to the client. When the client receives the common encryption key, data communication can be performed using the common encryption key thereafter.
【0029】
By following the above procedure, the information required for authentication becomes the decrypted data of the encrypted data, that is, the information before encryption), so even if the data is stolen on the route, it is illegal. It will not be available. As a result, even if data is stolen on the data transfer path, it cannot be abused as long as the encryption method is reliable.
【0030】
Also, the client-side public encryption key is dynamically generated, so it is different each time. Therefore, the reliability can be further improved. In addition, since the common encryption key sent from the server is dynamically generated after the authentication is established, the reliability is further improved.
【0031】
As described above, the cryptographic authentication method of the present invention has an effect that authentication can be performed even on a route for which security has not been established on the data transfer route. Further, at the time of authentication, communication is performed using a public encryption key / private encryption key, and after authentication is established, communication is performed using a common encryption key, so that the entire processing required for data communication can be reduced. Therefore, there is an effect that the load on the computer can be reduced.
【0032】
Next, the cryptographic authentication method according to the second embodiment of the present invention will be described.
【0033】
In the first embodiment described above, the effect that authentication is possible even on a route for which security has not been established on the data transfer route has been obtained, but security for the simulated server / simulated client has not yet been established. If a simulated server is used in the middle of the communication path, it is possible to obtain the information required for authentication from the client. The reverse is also possible.
【0034】
Therefore, in the cryptographic authentication method according to the second embodiment, a method for establishing security for the simulated server / simulated client is shown.
【0035】
In order to establish security for a mock server / mock client, it is better to create a situation where it must be a true server / true client, rather than checking whether it is mock or true. In this case, there is a method of guaranteeing the client and server by a third party server, but if there is a bad guy on the transfer route (especially just before the server when delivering data to the server), all the transfer data It's the same as a packet getting into the wrong hands, so it's a decisive move. In other words, it is meaningless if even a third party is simulated.
【0036】
That is where "tally" authentication is used. The specific procedure is as follows.
【0037】
When it wants to establish authentication between the server and the client, in step S12, the client dynamically randomly generates a client-side public encryption key and sends it to the server.
【0038】
In step S14, the server asks the client a question using the client-side public encryption key. This "question" is similar to the question in the first embodiment described above. At this time, the server sends the tally to the client using the client-side public encryption key.
【0039】
In step S16, the client asks for the server-side public encryption key from the tally from the server. For example, a server-side public encryption key is derived by applying a predetermined algorithm to a tally that is promised and held between the server and the server in advance. The client sends the answer to the question to the server using the obtained server-side public encryption key.
【0040】
If the answer to the question is correct, the client authentication is established up to step S16. At that time, in step S18, the server dynamically generates a common encryption key to be used for future communication, and transmits the common encryption key to the client using the client-side public encryption key. When the client receives the common encryption key, it can then communicate using the common encryption key.
【0041】
As described above, the difference from the cryptographic authentication method in the first embodiment is step S14. The point is that the server-side tally is transferred to the client at the same time as the "question". The tally is owned by both the server and the client, and by combining them, the "server-side public encryption key" used when transferring the answer to the server question can be obtained.
【0042】
As a concrete example, if the server-side tally is SS and the client-side tally is CS, (Server-side public encryption key) = SS XOR CS (XOR is the exclusive OR). The function for calculating the server-side public encryption key is not limited to XOR. More sophisticated algorithms can be used to increase security.
【0043】
Since the true client's tally is known if it is a true server, the server-side public encryption key after derivation can be changed every time by dynamically generating the tally.
【0044】
If the relationship is not true server and true client, the mock client cannot obtain the server-side public encryption key to be used when answering. That is, since the tally of the true client is unknown, the server-side public encryption key cannot be derived. Also, the mock server cannot get the correct "answer" (the answer from the true client to the true server) because the tally of the true client is unknown.
【0045】
The cryptographic authentication method according to the present invention can be applied to various types of authentication, and will be described below by taking bank remittance on the Internet as an example. The server is a bank on the Internet, and the client is a home or corporate terminal. Let the user be the person operating the terminal. In the following description, the authentication applet is an application that runs on the client side.
【0046】
The client accesses the bank's homepage with a Web browser. At the same time, the authentication dialog realized by Java applet or ActiveX control appears. The software that generates this authentication dialog (hereinafter referred to as an authentication applet) authenticates according to the procedure of the cryptographic authentication method of the present invention. If the authentication applet is a Java applet and is downloaded, check for tampering with JDK1.1 migration.
【0047】
Here, when the user selects remittance, the authentication applet generates a client-side public encryption key from true random numbers, user-specific data, and the like. Here, it is created every time it is certified in order to improve security. The authentication applet sends the client-side public encryption key to the server.
【0048】
The authentication applet then asks the user for the user's account number and PIN. The authentication applet asks the server for a tally. The authentication applet derives the server-side public encryption key from the tally. The authentication applet then uses the server-side public encryption key to send the account number and PIN to the server.
【0049】
After that, when the authentication applet receives the common encryption key and the identification code from the server (the subsequent encryption communication using this common encryption key is performed for the server-client communication), the authentication applet informs the user. Request the account number and amount of the remittance destination. The authentication applet then sends the remittance destination account number to the server.
【0050】
Upon receiving the remittance destination information from the server, the authentication applet displays the remittance destination information to the user and asks for confirmation. When the user determines that the remittance destination / amount is OK, the authentication applet sends the remittance destination, amount, and identification code to the server.
【0051】
Upon receiving the confirmation information from the server, the authentication applet displays the confirmation information to the user. With the above, the bank remittance process is completed.
【0052】
Here, we have given an example that assumes implementation with a widely used Web browser and Java of Sun Microsystems or ActiveX component of Microsoft.
【0053】
Next, the cryptographic authentication method of the present invention will be described by taking electronic money as an example. Here, the server is the issuing organization of electronic money, the client is the IC card, and the user is the owner of the IC card. In this case, the cash register can be considered as a node. Therefore, the cryptographic authentication method of the present invention can be applied even in such a form.
【0054】
In this example, the cash register is relayed when the IC card communicates with the issuing institution of electronic money. If this cash register is a bad guy, it is a data transfer path, so it can be stolen or tampered with, and an unreasonable amount may be paid. However, if the cryptographic authentication method of the present invention is applied, , This security hole can be filled. Of course, if the cryptographic authentication method according to the second embodiment is applied, it is possible to protect the simulated IC card and the simulated electronic money issuing organization.
【0055】
As described above, the cryptographic authentication method of the present invention can be used for authentication of a computer in general, and is particularly applicable to the following examples.
【0056】
Confirmation between the direct parties of a good or service transaction on a commercial server. In this case, the content of the authentication is the authentication of the mall, the authentication of the ordering server, and the like. The assumed certificate authority is a third-party organization, including network operators.
【0057】
Confirmation at the time of settlement in bank / credit transactions. In this case, the content of the certification is cardholder certification, member store certification, financial institution certification, and the like. Possible certificate authorities are banks, credit companies, and include third-party institutions that are outsourced from financial institutions.
【0058】
Confirmation of the other party of the e-mail in the security mail. In this case, the content of the authentication is an individual authentication. The assumed certificate authority is a third-party organization, including network operators.
【0059】
Confirmation of group members in groupware. In this case, the content of the certification is personal confirmation, and the assumed certification authority is a company, an organization, and a third party organization that is outsourced from the company / organization.
【0060】
Confirmation at the time of administrative services in public business. In this case, the content of the certification is individual certification and group certification, and the assumed certification authority is a public institution.
【0061】
[Effect of the invention]
As described above, according to the present invention, it is possible to perform secure authentication / communication even in a network in which security has not been established on the transfer path. In addition, it is possible to prevent the theft and spoofing of authentication information by the simulated server and the simulated client. As a result, the development of the electronic network society can be further accelerated.
[Simple explanation of drawings]
[Figure 1]
It is a timing diagram for demonstrating the procedure of the cryptographic authentication method which concerns on 1st Embodiment of this invention.
[Figure 2]
It is a timing diagram for demonstrating the procedure of the cryptographic authentication method which concerns on 2nd Embodiment of this invention.
[Fig. 3]
It is a timing diagram for demonstrating the procedure of the conventional cryptographic authentication method.
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US8977714B2 | Cited by | United States of America | Applicant |
| US8291084B2 | Cited by | United States of America | Applicant |
| JP2002232675A | Cited by | Japan | Search report |
| US7937580B2 | Cited by | United States of America | Applicant |
| JP2002297920A | Cited by | Japan | Search report |
| WO0171516A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| WO03032175A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US7284125B2 | Cited by | United States of America | Applicant |
2 priority claims, no other members on record
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 13933497 | Japan | A | |
| JP19970139334 | – | – | – |
1 legal event, as the office reported them to INPADOC
Events
| Event | Code | |
|---|---|---|
| Application deemed to be withdrawn because no request for examination was validly filedWithdrawnJAPANESE INTERMEDIATE CODE: A300A300 | A300 |
Numbers
- Publication
- 10-322325
- Publication, DOCDB
- H10322325
- Publication, EPODOC
- JPH10322325
- Application
- 9139334
- Application, DOCDB
- 13933497
- Application, EPODOC
- JP19970139334
Titles2
- Japanese
- 【発明の名称】暗号認証方式
- English
- [Title of Invention] Cryptographic Authentication Method
Classification
- IPC, 3
- G06F13 00
- H04L9 08
- H04L9 32