CN110855444A - Pure software CAVA identity authentication method based on trusted third party - Google Patents

Pure software CAVA identity authentication method based on trusted third party Download PDF

Info

Publication number
CN110855444A
CN110855444A CN201911061547.1A CN201911061547A CN110855444A CN 110855444 A CN110855444 A CN 110855444A CN 201911061547 A CN201911061547 A CN 201911061547A CN 110855444 A CN110855444 A CN 110855444A
Authority
CN
China
Prior art keywords
consumer
payment platform
merchant system
request
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201911061547.1A
Other languages
Chinese (zh)
Inventor
王亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Institute of Graphic Communication
Original Assignee
Beijing Institute of Graphic Communication
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Institute of Graphic Communication filed Critical Beijing Institute of Graphic Communication
Priority to CN201911061547.1A priority Critical patent/CN110855444A/en
Publication of CN110855444A publication Critical patent/CN110855444A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Abstract

The invention discloses a pure software CAVA identity authentication method based on a trusted third party, which is characterized in that an identity authentication request process is verified in advance, and a server side can not process the request which does not pass the verification in advance, so that denial of service attack can be effectively resisted. In addition, by introducing a trusted third party, bidirectional identity authentication is realized, and phishing attack can be effectively resisted. On one hand, the invention can reduce the calculation intensity of both the server and the client, simplify the flow of user authentication and authorization and effectively improve the authentication efficiency.

Description

Pure software CAVA identity authentication method based on trusted third party
Technical Field
The invention belongs to the technical field of information, is applied to the electronic commerce industry, and particularly relates to a pure software CAVA identity authentication method based on a trusted third party.
Background
The existing two-party identity authentication generally refers to the mutual identity authentication only through negotiation, information exchange and judgment of two transaction parties. The authentication mode does not need the participation of a third party, has simple process, but cannot accurately determine the identities of the two parties. The following two-party identity authentication mechanisms are mainly used.
(1) Single factor identity authentication
The single-factor authentication is generally based on a password, and the authentication method is a process in which an account and password information are input by a verifier, and the verifier performs identity authentication by comparing the input information to be verified with verifier information stored by the verifier. The account number and password are generally reserved when the verifier registers, and the information is stored in a database of the verifier after being encrypted.
Lamport presented a one-time password based authentication scheme in 1981. In this authentication scheme, the verifier performs the purpose of authentication by comparing the password input by the verifier with a password table stored in advance in the verifier server. Subsequently, Shimizu, Hailer and Sandirigama et al performed improvements in safety, performance and efficiency based on the Lamport solution. The scheme has the advantage of easy implementation, but the verifier end needs to store the user password or the password table, and once the password is lost due to database leak of the verifier end or the password table rule is cracked, the security of the authentication system is threatened. Meanwhile, the scheme is mainly oriented to one-way authentication, bidirectional authentication cannot be realized, and counterfeiting and phishing attacks are easily caused.
Harn et al propose a password authentication scheme based on an asymmetric key system based on the Diffie-Hellman public key encryption technology. This scheme does not require special protection of information relating to the user password on the verifier side, nor involvement of the verifier in updating the relevant verification information.
Peyradian and Zunec propose a lightweight one-way identity authentication protocol based on a digest algorithm, but the protocol has security problems such as easy phishing attack. In order to solve the problems existing in the protocol, the improvement scheme is proposed by Hwang et al in the literature, Lee et al respectively for the Peyravain-Zunec protocol, and the Peyravain also proposes the optimization scheme for the self protocol. Later, Zhu et al proposed an improved protocol based on the Hwang-Yeh protocol, but this improved protocol was deficient in resisting impersonation attacks and key agreement. Islam et al have proposed an improved protocol based on the Hwang-Yeh protocol for solving the above problems.
(2) Multi-factor identity authentication
The password-based single-factor identity authentication has many problems, for example, the user password is stored in the authenticator server, and the technical level and consciousness of the authenticator are not uniform, which results in potential data security hazard and easy leakage of user information. The attacker can attack by means of stealing, analyzing, decrypting and even 'bumping into the library'. In addition, the single-factor identity authentication based on the password is one-way, the server can authenticate the identity of the user, but the user cannot authenticate the identity of the server, and therefore phishing and counterfeiting are possible.
The smart card is an information device which is not easy to counterfeit, is generally issued by an authenticator and supports high-strength encryption, and can solve the problems to a certain extent by jointly realizing identity authentication by using the smart card and a password. In 1991, Chang and Wu proposed a two-factor identity authentication protocol based on a smart card and a password. Lee and Chang first propose an authentication system based on user identity and distributed keys, but the protocol has weak protection against counterfeit attacks. Tsuar and Wu et al propose an identity authentication protocol based on an asymmetric encryption algorithm RSA, Li and Lin et al propose an identity authentication protocol based on a neural network, but the protocol has a large load on hardware. Lin and Hwang et al improved on this problem. Chang and Lee et al propose a key generation algorithm without a preset table, but the key generated by the algorithm is not dynamic and is easy to be attacked by counterfeiting. In 2009, Liao and Wang proposed an authentication protocol based on dynamic id, and Hsiang and Shih proposed an improved scheme of replacing static id with dynamic id. Thereafter, Shao and Chin et al and Wang and Ma et al have further refined the security and weight reduction issues, respectively. In 2011, Wen and Li indicate that the Wang-Ma protocol has the possibility of counterfeiting and password speculation attacks, and provide an improved dynamic key agreement identity authentication protocol based on the Wang-Ma protocol, wherein the protocol is calculated based on a hash function, has high efficiency, and simultaneously has internal security risks and is likely to suffer from counterfeiting or phishing attacks.
(3) Challenge-response authentication
Challenge-Response (Challenge-Response) authentication is a typical zero-knowledge proof authentication approach. In current mobile commerce, an identity authentication mechanism combining password authentication and challenge-response authentication is widely used.
The principle of challenge-response authentication is that a verifier server sends random challenge information to a verifier during each authentication, the information is generally a character string, the verifier responds to the verifier after receiving the information, and the verifier verifies whether the identity of the verifier is legal or not according to a response result. The authentication process is shown in fig. 2.
The challenge-response authentication scheme is initiated by the verifier irregularly, so that if the verifier requests authentication frequently, a large resource consumption is brought to the authentication server, the network service provider and the client. Meanwhile, the authentication scheme has more manual participation processes and has larger influence on the information sending and receiving mobile communication network and the provider, so that delay can be caused. The challenge-response authentication scheme is more suitable for the identity authentication process in which only two parties participate.
Disclosure of Invention
Aiming at the defects of the prior art, the invention aims to provide a pure software CAVA identity authentication method based on a trusted third party.
In order to achieve the purpose, the invention adopts the following technical scheme:
a pure software CAVA identity authentication method based on a trusted third party comprises the following steps:
(1) and (3) applying a digital certificate:
s1.1, the consumer Ru and the payment platform Rp respectively send requests for applying for digital certificates to a Certificate Authority (CA);
s1.2, after the certification center CA verifies the request for applying the digital certificate, the certification center CA respectively issues the digital certificate CER for the consumer Ru and the payment platform RpuAnd CERpThe digital certificate comprises respective basic information INFO, a public key PUK and a digital signature DS of a certificate authority CA of the identity authentication participants;
(2) contract initialization stage:
s2.1, the consumer Ru sends a contract establishing request to the payment platform Rp and sends a contract establishing request including an ID to the payment platform RpupAnd INFOuThe basic information inside; wherein the IDupIdentity identifier ID representing consumer Ru in payment platform Rpup；INFOuNon-security information representing consumer Ru;
s2.2, after receiving the contract establishing request, the payment platform Rp conducts auditing;
s2.3, after the audit is passed, the payment platform Rp sends an audit success message to the consumer Ru;
s2.4, after receiving the success message, the consumer Ru and the payment platform Rp respectively request the CER of the digital certificate of the other party from the authentication center CApAnd CERu，CERpDigital certificate, CER, representing a payment platform RpuA digital certificate representing consumer Ru; because the digital certificate contains the real identity information of the consumer Ru and the payment platform Rp and a trusted third party, namely the authentication center CA, provides guarantee through digital signature, the consumer Ru and the payment platform Rp can confirm the identity of the other party through the digital certificate in a two-way manner;
s2.5, after receiving the digital certificate requests of the consumer Ru and the payment platform Rp, the authentication center extracts the digital certificate CERpAnd CERu；
S2.6, the certification center CA sends digital certificates CER to the consumers Ru and the payment platform Rp respectivelypAnd CERu；
S2.7, after the consumer Ru and the payment platform Rp receive the digital certificate of the other party, verifying the digital signature DS of the authentication center CA and confirming the real identity of the other party, and agreeing to the achievement, wherein the payment platform Rp stores INFOu；
(3) Registration stage of business process:
s3.1, the consumer Ru sends a registration request to the merchant system Rb and sends a registration request including the ID to the merchant system RbubAnd INFOuThe basic information inside; IDubAn identity identifier representing the consumer Ru in the merchant system Rb;
s3.2, after receiving the registration request, the merchant system Rb carries out verification firstly; after the verification is passed, sending a system message MSG to the consumer Ru;
s3.3, after receiving the system message MSG, the consumer Ru sets the password PW by itselfubObtaining a security token ST through a hash algorithm for 1 timeubAnd secure token STubSending the data to Rb;
s3.4, receiving the security token ST by the merchant system RbubThen, ST is storedubAnd INFOu；
(4) Login stage of business process:
s4.1, Consumer Ru sends a login request to the merchant system Rb and sends an ID to the merchant system Rbub、STubAnd security information such as SI; SI indicates DeIDubAnd PWubSecurity information of the outside;
s4.2, after receiving the login request, the merchant system Rb carries out the login processing according to the ID of the consumer RuubRetrieving a reserved security token ST from a databaseubAnd auditing is carried out; after the verification is passed, sending a system message MSG to the consumer Ru;
(5) and (3) settlement stage:
s5.1, the consumer Ru sends a settlement request to the merchant system Rb and sends an ID to the merchant system RbupEstablishing a trust relationship between Rb and Rp;
s5.2, after the merchant system Rb receives the settlement request, the ID is sentupForwarding to a payment platform Rp;
s5.3, the payment platform Rp is according to the IDupInquiring the relevant information of the consumer Ru from the database, if the relevant information is not inquired, returning relevant error information, if the relevant information is inquired, generating a random character string S, and sending the S to the merchant system Rb;
s5.4, the merchant system Rb forwards the random character string S to the consumer Ru after receiving the random character string S;
s5.5, after the consumer Ru receives the random character string S, the random character string S utilizes the private key PRK stored locallyuEncrypting the random string S to obtain a security token STupAnd secure token STupSending to the merchant system Rb;
s5.6, after the merchant system Rb receives the security token STupThen forwarding to a payment platform Rp;
s5.7, the payment platform Rp receives the security token STupThereafter, a digital certificate CER of the consumer Ru is requested from the certificate authority CAuVerifying the digital signature of the certification center CA and then receiving the certificate from the CERuPublic key PUK for extracting Ru of consumeru；
S5.8, the payment platform utilizes the public key PUK of the Ru of the consumeruDecrypting a security token STupAnd obtaining S ', if S is equal to S', establishing a TRUST relationship TRUST and sending a system message informing that the verification is successful, and if the verification is lostIf the verification fails, the system message passing the verification failure is sent;
s5.9, establishing a trust relationship between the merchant system Rb and the payment platform Rp;
s5.10, the merchant system Rb sends a settlement request to the payment platform Rp and sends settlement information M;
s5.11, the payment platform Rp settles the account to the merchant system Rb;
s5.12, if the settlement is successful, the payment platform Rp returns a settlement successful message to the merchant system Rb;
s5.13, the merchant system Rb returns a settlement success message to the consumer Ru.
Further, the method also comprises the following steps:
(6) contract maintenance stage:
s6.1, the consumer Ru initiatively initiates a contract maintenance request to the payment platform Rp and sends the contract maintenance request including the ID encrypted by the private key to the payment platform Rpup、STupAnd INFOuThe basic information inside; the contract maintenance is mainly used for modifying related information INFO of the consumer Ruu；
S6.2, after receiving the maintenance contract request, the payment platform Rp conducts auditing, and the audited content comprises information integrity and identifier uniqueness; requesting the certificate authority CA for the digital certificate CER of the consumer Ru after the successful audituAnd extracting public key PUK of consumer Ruu；
S6.3, payment platform Rp uses public key PUK of consumer RuuDecryption INFOuThen using the decrypted INFOuReplace original INFO'u。
Further, in step S2.2, the audited content includes information integrity and identifier uniqueness.
Further, in step S3.2, the audited content includes information integrity and identifier uniqueness.
The invention has the beneficial effects that:
(1) can resist denial of service attack
The invention verifies the identity authentication request process in advance, and the request which does not pass the verification in advance can not be processed by the server, thereby effectively resisting the attack of denial of service.
(2) Resisting phishing attacks
The invention introduces a trusted third party to realize bidirectional identity authentication and effectively resist phishing attacks.
(3) Efficiency of authentication
On one hand, the invention can reduce the calculation intensity of both the server and the client, simplify the flow of user authentication and authorization and effectively improve the authentication efficiency.
(4) DoS and dictionary attack resistance
In the present invention, the settlement request of the consumer Ru is not actively triggered by Ru, but passively triggered by the information sent by Rp. Namely: after completing the business process, the consumer Ru makes a settlement request to a merchant system Rb, and the Rb receives the request and then puts the Ru on the unique identifier ID in the payment platform RpupSending to Rp, Rp will inquire ID in databaseupThe authenticity of the connection is reestablished. In the process, firstly, Ru cannot actively send a settlement request, and then an attacker cannot actively send the settlement request, so that the attacker is difficult to achieve an active anonymous request, and the possibility of occurrence of DoS attack and dictionary attack is reduced.
(5) Anti-spoofing and replay attacks
In the invention, after each time Ru proposes a login request, Rp sends a random string S to a client, Rp receives the request and requires Rb to forward the random string S to Ru, and Ru needs to utilize a private key PRK after receiving SuEncrypting S and encrypting the encrypted security token STupSending the information to Rp, wherein the Rp utilizes the public key PUK of the consumer stored in the contract establishing stageuAnd decrypting, and comparing S' obtained by decryption with S. This random string S is destroyed after each successful login by the user. Based on the above-described flow, the following conclusions can be drawn.
a) Key Pair (PRK) for consumer Ruu,PUKu) Only during the contract establishment phase, where the merchant system Rb does not participate, it is not possible for Rb to obtain the key;
b) since the character string S in each settlement process isRandomly generated, therefore STup(by PRK)uEncrypted S) is also unique, and the merchant system Rb cannot capture the ST from this settlement processupFor later settlement.
Based on the analysis, the scheme can effectively prevent impersonation and replay attacks.
(6) Anti-transaction repudiation
Based on the workflow of the present invention, the following conclusions can be drawn.
a) Private key PRK of Consumer RuuThe Ru shares information independently and is approved by both Ru and Rp in the contract establishing stage, and Ru utilizes PRK in the settlement processuThe random string S is digitally signed. This process is non-repudiatable, as can be seen from the basic principles of symmetric encryption and digital signatures.
b) In each key process of the invention, a log storage link is provided, and the log can guarantee the authenticity of the historical transaction.
Based on the above analysis, Ru cannot deny the authenticity of a transaction that has occurred under normal circumstances, i.e., the present invention can effectively prevent transaction repudiation.
Drawings
FIG. 1 is a diagram of the components of a prior art identity authentication system;
FIG. 2 is a diagram illustrating a challenge-response authentication process in the prior art of identity authentication;
FIG. 3 is a flow chart illustrating a digital certificate application phase according to an embodiment of the present invention;
FIG. 4 is a schematic flow chart of a contract initialization phase according to an embodiment of the present invention;
FIG. 5 is a flow chart illustrating a registration phase of a business process according to an embodiment of the present invention;
FIG. 6 is a flow diagram illustrating a login phase of a business process in accordance with an embodiment of the present invention;
FIG. 7 is a flow chart illustrating a settlement stage according to an embodiment of the present invention;
fig. 8 is a schematic flow chart of the contract maintenance phase in the embodiment of the present invention.
Detailed Description
The present invention will be further described with reference to the accompanying drawings, and it should be noted that the present embodiment is based on the technical solution, and the detailed implementation and the specific operation process are provided, but the protection scope of the present invention is not limited to the present embodiment.
1. Some technical terms in the field are briefly described below
1) Cipher and encryption algorithm
Cryptography is a branch of information theory and is responsible for all the steps involved in handling secure messages, including authentication, digital signatures and key management. In brief, encryption is a process that rearranges plaintext information in some way to make it unintelligible ciphertext information, and the recipient of the information restores the ciphertext information to plaintext information and then uses it in the reverse process. We can explain the encryption and decryption process with the following definitions and flow.
Defining: encryption algorithm
The information in the encryption and decryption process is defined as follows:
(1)Mp: plaintext original information of an information sender;
(2) k: message sender for encrypting MpThe secret key of (a);
(3)Mc: the information sender will MpCarrying out encryption to obtain a ciphertext;
(4)Mc': the message receiver receives the ciphertext;
(5) k': message receiver for decrypting Mc' of a key;
(6)Mp': will Mc' plaintext information obtained after decryption.
Then, the encryption algorithm can be defined as:
E:(Mp+K)→Mc
the decryption algorithm may be defined as:
E’:(Mc’+K’)→Mp’
2) identity authentication
Identity Authentication (Identity Authentication) is a process of authenticating whether the Identity of a business participant is legitimate, and is the basis on which the entire business activity can run. The basic principle of identity authentication is to verify the relevant information of the authenticated party to realize identity confirmation. With the rapid development of electronic commerce, especially mobile commerce, authenticating the identity of business participants and ensuring the security of each party is becoming one of the most critical processes in the mobile commerce process. The identity authentication technology can be classified into one-way authentication and two-way authentication according to the authentication level and the authentication entity, and the characteristics and the applicable environment thereof are shown in table 1.
TABLE 1 one-way and two-way identity authentication
Figure BDA0002258088670000121
A common identity authentication system includes the following parts: the authentication protocol, the business participants, the authentication information and the attackers, etc., as shown in fig. 1.
Based on the above basic elements, we can describe the basic functions that the identity authentication system should have. As shown in table 2. Generally, identity authentication schemes can be divided into two categories: simple authentication schemes and high-strength authentication schemes. The identity authentication information of the simple identity authentication scheme only contains key information such as account numbers, passwords and the like, and the information is generally transmitted in an unencrypted form. However, non-encrypted information is very easy to be obtained illegally, and the general solution is to process the information by a hash function (such as MD5 or SHA) or use a dynamic password (OTP), and by using these solutions, even if the plaintext of the information is stolen, the original identity authentication information cannot be derived. High-strength identity authentication schemes will typically employ a hybrid encryption mechanism to prevent sensitive data from being illegally acquired and used during authentication. For example, the Kerberos protocol is a widely used strong authentication scheme. The emerging high-strength identity authentication scheme integrates the technologies of a trusted third party, challenge/response, a smart card, even biometric identification and the like, and realizes higher-strength identity authentication. Several common authentication schemes are listed below and their features and application environments are discussed.
Table 2 main functions of the authentication system
Figure BDA0002258088670000131
Figure BDA0002258088670000151
3) Dynamic password
The dynamic Password is also called a One Time Password (One Time Password). The secret information used by the dynamic password is different in each transaction process, and even if an attacker obtains the safety information in a certain transaction process by some means, the attacker cannot be used for the next transaction.
The basic principle of dynamic passwords is: the authenticated party first makes an authentication request, and the authenticator generates a dynamic message according to the authentication request, wherein the dynamic message may be any unique message which cannot be inferred, such as a random number or a time stamp, or a unique message which is calculated or combined on the basis of a fixed message, such as a value obtained by a dynamic encryption or digest algorithm.
Due to the uniqueness and the inconsistency of the dynamic password, the identity authentication technology based on the dynamic password can prevent eavesdropping and replay attacks to a certain extent and can also reduce the risk of subsequent chain security problems caused by the security defects of a business system. Typical dynamic passwords are shown in table 3.
TABLE 3 exemplary dynamic password
Figure BDA0002258088670000152
Figure BDA0002258088670000161
Compared to conventional static password authentication techniques, the dynamic password has the characteristics described in table 4:
TABLE 4 characteristics of dynamic passwords
Figure BDA0002258088670000162
Figure BDA0002258088670000171
2. Description of the method
The parameters and their symbols used for the description of the method are shown in table 5:
TABLE 5 symbolic description of the present solution
Figure BDA0002258088670000181
The method comprises the following steps:
(1) the digital certificate application phase, as shown in fig. 3:
s1.1, the consumer Ru and the payment platform Rp respectively send requests for applying for digital certificates to a Certificate Authority (CA);
s1.2, after the certification center CA verifies the request for applying the digital certificate, the certification center CA respectively issues the digital certificate CER for the consumer Ru and the payment platform RpuAnd CERpThe digital certificate comprises respective basic information INFO, a public key PUK and a digital signature DS of a certificate authority CA of the identity authentication participants;
(2) contract initialization phase, as shown in fig. 4:
s2.1, the consumer Ru sends a contract establishing request to the payment platform Rp and sends a contract establishing request including an ID to the payment platform RpupAnd INFOuThe basic information inside; wherein the IDupIdentity identifier ID representing consumer Ru in payment platform Rpup；INFOuNon-security information representing consumer Ru; typically, the non-security information includes nickname, gender, and,Interest, integration, etc.
S2.2, after receiving the contract establishing request, the payment platform Rp conducts auditing, and the audited content comprises information integrity and identifier uniqueness;
s2.3, after the audit is passed, the payment platform Rp sends an audit success message to the consumer Ru;
s2.4, after receiving the success message, the consumer Ru and the payment platform Rp respectively request the CER of the digital certificate of the other party from the authentication center CApAnd CERu，CERpDigital certificate, CER, representing a payment platform RpuA digital certificate representing consumer Ru; because the digital certificate contains the real identity information of the consumer Ru and the payment platform Rp and a trusted third party, namely the authentication center CA, provides guarantee through digital signature, the consumer Ru and the payment platform Rp can confirm the identity of the other party through the digital certificate in a two-way manner;
s2.5, after receiving the digital certificate requests of the consumer Ru and the payment platform Rp, the authentication center extracts the digital certificate CERpAnd CERu；
S2.6, the certification center CA sends digital certificates CER to the consumers Ru and the payment platform Rp respectivelypAnd CERu；
S2.7, after the consumer Ru and the payment platform Rp receive the digital certificate of the other party, verifying the digital signature DS of the authentication center CA and confirming the real identity of the other party, and agreeing to the achievement, wherein the payment platform Rp stores INFOu。
(3) The registration phase of the business process, as shown in fig. 5:
s3.1, the consumer Ru sends a registration request to the merchant system Rb and sends a registration request including the ID to the merchant system RbubAnd INFOuThe basic information inside; IDubAn identity identifier representing the consumer Ru in the merchant system Rb;
s3.2, after receiving the registration request, the merchant system Rb carries out verification firstly, and the verified content comprises information integrity and identifier uniqueness; after the verification is passed, sending a system message MSG to the consumer Ru;
s3.3, after receiving the system message MSG, the consumer Ru sets the password PW by itselfubObtaining a security token ST through a hash algorithm for 1 timeubAnd secure token STubSending the data to Rb;
STub＝HASH(PWub)；
s3.4, receiving the security token ST by the merchant system RbubThen, ST is storedubAnd INFOu；
(4) The login phase of the business process, as shown in FIG. 6:
s4.1, the consumer Ru sends a login request to the merchant system Rb and sends an ID to the merchant system Rbub、STubAnd security information such as SI; SI indicates DeIDubAnd PWubExternal security information such as authentication codes and challenge/response information;
s4.2, after receiving the login request, the merchant system Rb carries out the login processing according to the ID of the consumer RuubRetrieving a reserved security token ST from a databaseubAnd performing audit, wherein the audit content comprises ST in the login request of the calculation judgment userubAnd a security token ST in a databaseubWhether the two are consistent; after the verification is passed, sending a system message MSG to the consumer Ru;
(5) settlement phase, as shown in fig. 7:
s5.1, the consumer Ru sends a settlement request to the merchant system Rb and sends an ID to the merchant system RbupEstablishing a trust relationship between Rb and Rp;
s5.2, after the merchant system Rb receives the settlement request, the ID is sentupForwarding to a payment platform Rp;
s5.3, the payment platform Rp is according to the IDupInquiring the relevant information of the consumer Ru from the database, if the relevant information is not inquired, returning relevant error information, if the relevant information is inquired, generating a random character string S, and sending the S to the merchant system Rb;
s5.4, the merchant system Rb forwards the random character string S to the consumer Ru after receiving the random character string S;
s5.5, after the consumer Ru receives the random character string S, the random character string S utilizes the private key PRK stored locallyuEncrypting the random string S to obtain a security token STupAnd secure token STupSending to the merchant system Rb;
STup＝EC(S)PRKu；
EC(S)PRKurepresentation with private key PRKuEncrypting the random character string S;
s5.6, after the merchant system Rb receives the security token STupThen forwarding to a payment platform Rp;
s5.7, the payment platform Rp receives the security token STupThereafter, a digital certificate CER of the consumer Ru is requested from the certificate authority CAuVerifying the digital signature of the certification center CA and then receiving the certificate from the CERuPublic key PUK for extracting Ru of consumeru；
S5.8, the payment platform utilizes the public key PUK of the Ru of the consumeruDecrypting a security token STupObtaining S ', if S is equal to S', establishing a TRUST relationship TRUST and sending a system message informing that the verification is successful, and if the verification is failed, sending the system message which passes the verification failure;
S’＝DC(STup)PUKu；
DC(STup)PUKurepresenting by using public key PUKuDecrypting STup；
S5.9, establishing a trust relationship between the merchant system Rb and the payment platform Rp;
TRUST＝IsTrue(S＝S’)；
istrue () represents a function that determines whether a condition holds;
s5.10, the merchant system Rb sends a settlement request to the payment platform Rp and sends settlement information M;
s5.11, the payment platform Rp settles the account to the merchant system Rb;
s5.12, if the settlement is successful, the payment platform Rp returns a settlement successful message to the merchant system Rb;
s5.13, the merchant system Rb returns a settlement success message to the consumer Ru.
(6) Contract maintenance phase, as shown in fig. 8:
s6.1, the consumer Ru initiatively initiates a contract maintenance request to the payment platform Rp and sends the contract maintenance request including the ID encrypted by the private key to the payment platform Rpup、STupAnd INFOuThe basic information inside; the purpose of contract maintenance is generally to modify the information INFO about the consumer Ruu；
S6.2, after receiving the maintenance contract request, the payment platform Rp conducts auditing, and the audited content comprises information integrity and identifier uniqueness; requesting the certificate authority CA for the digital certificate CER of the consumer Ru after the successful audituAnd extracting public key PUK of consumer Ruu；
INFOu＝new(INFOu)；
S6.3, payment platform Rp uses public key PUK of consumer RuuDecryption INFOuThen using the decrypted INFOuReplace original INFO'u：
INFOu＝DC(new(INFOu))PUKu；
INFO’u＝INFOu。
Compared with the prior art, the method of the embodiment mainly has the following advantages:
(1) can resist denial of service attack
The method of the embodiment verifies the identity authentication request process in advance, and the request which does not pass the verification in advance can not be processed by the server side any more, so that the denial of service attack can be effectively resisted.
(2) Resisting phishing attacks
The method introduces the trusted third party, realizes bidirectional identity authentication, and can effectively resist phishing attacks.
(3) Efficiency of authentication
On one hand, the method can reduce the calculation intensity of both the server side and the client side, simplify the flow of user authentication and authorization, and effectively improve the authentication efficiency.
(4) DoS and dictionary attack resistance
In this scenario, the settlement request of the consumer Ru is not actively triggered by Ru, but passively triggered by the information sent by Rp. Namely: after completing the business process, the consumer Ru makes a settlement request to a merchant system Rb, and the Rb receives the request and then puts the Ru on the unique identifier ID in the payment platform RpupSending to Rp, Rp will inquire ID in databaseupThe authenticity of the connection is reestablished. In the process, firstly, Ru cannot actively send a settlement request, and then an attacker cannot actively send the settlement request, so that the attacker is difficult to achieve an active anonymous request, and the possibility of occurrence of DoS attack and dictionary attack is reduced.
(5) Anti-spoofing and replay attacks
In the scheme, each time Ru submits a login request, Rp sends a random string S to a client, Rp receives the request and requires Rb to forward the random string S to Ru, and Ru needs to utilize a private key PRK after receiving SuEncrypting S and encrypting the encrypted security token STupSending the information to Rp, wherein the Rp utilizes the public key PUK of the consumer stored in the contract establishing stageuAnd decrypting, and comparing S' obtained by decryption with S. This random string S is destroyed after each successful login by the user. Based on the above-described flow, the following conclusions can be drawn.
a) Key Pair (PRK) for consumer Ruu,PUKu) Only during the contract establishment phase, where the merchant system Rb does not participate, it is not possible for Rb to obtain the key;
b) since the string S is randomly generated during each settlement, STup(by PRK)uEncrypted S) is also unique, and the merchant system Rb cannot capture the ST from this settlement processupFor later settlement.
Based on the analysis, the scheme can effectively prevent impersonation and replay attacks.
(6) Anti-transaction repudiation
Based on the workflow of the present solution, the following conclusions can be drawn.
a) Private key PRK of Consumer RuuThe Ru shares information independently and is approved by both Ru and Rp in the contract establishing stage, and Ru utilizes PRK in the settlement processuThe random string S is digitally signed. This process is non-repudiatable, as can be seen from the basic principles of symmetric encryption and digital signatures.
b) In each key process of the scheme, a log storage link is provided, and the log can guarantee the authenticity of historical transactions.
Based on the analysis, the authenticity of the transaction which has occurred cannot be denied by Ru under normal conditions, namely, the scheme can effectively prevent the transaction from being repudiated.
Various corresponding changes and modifications can be made by those skilled in the art based on the above technical solutions and concepts, and all such changes and modifications should be included in the protection scope of the present invention.

Claims (4)

1. A pure software CAVA identity authentication method based on a trusted third party is characterized by comprising the following steps:
(1) and (3) applying a digital certificate:
s1.1, the consumer Ru and the payment platform Rp respectively send requests for applying for digital certificates to a Certificate Authority (CA);
s1.2, after the certification center CA verifies the request for applying the digital certificate, the certification center CA respectively issues the digital certificate CER for the consumer Ru and the payment platform RpuAnd CERpThe digital certificate comprises respective basic information INFO, a public key PUK and a digital signature DS of a certificate authority CA of the identity authentication participants;
(2) contract initialization stage:
s2.1, the consumer Ru sends a contract establishing request to the payment platform Rp and sends a contract establishing request including an ID to the payment platform RpupAnd INFOuThe basic information inside; wherein the IDupIdentity identifier ID representing consumer Ru in payment platform Rpup；INFOuNon-security information representing consumer Ru;
s2.2, after receiving the contract establishing request, the payment platform Rp conducts auditing;
s2.3, after the audit is passed, the payment platform Rp sends an audit success message to the consumer Ru;
s2.4, after receiving the success message, the consumer Ru and the payment platform Rp respectively request the CER of the digital certificate of the other party from the authentication center CApAnd CERu，CERpDigital certificate, CER, representing a payment platform RpuA digital certificate representing consumer Ru; because the digital certificate contains the real identity information of the consumer Ru and the payment platform Rp and a trusted third party, namely the authentication center CA, provides guarantee through digital signature, the consumer Ru and the payment platform Rp can confirm the identity of the other party through the digital certificate in a two-way manner;
s2.5, after receiving the digital certificate requests of the consumer Ru and the payment platform Rp, the authentication center extracts the digital certificate CERpAnd CERu；
S2.6, the certification center CA sends digital certificates CER to the consumers Ru and the payment platform Rp respectivelypAnd CERu；
S2.7, after the consumer Ru and the payment platform Rp receive the digital certificate of the other party, verifying the digital signature DS of the authentication center CA and confirming the real identity of the other party, and agreeing to the achievement, wherein the payment platform Rp stores INFOu；
(3) Registration stage of business process:
s3.1, the consumer Ru sends a registration request to the merchant system Rb and sends a registration request including the ID to the merchant system RbubAnd INFOuThe basic information inside; IDubAn identity identifier representing the consumer Ru in the merchant system Rb;
s3.2, after receiving the registration request, the merchant system Rb carries out verification firstly; after the verification is passed, sending a system message MSG to the consumer Ru;
s3.3, after receiving the system message MSG, the consumer Ru sets the password PW by itselfubObtaining a security token ST through a hash algorithm for 1 timeubAnd secure token STubSending the data to Rb;
s3.4, receiving the security token ST by the merchant system RbubThen, ST is storedubAnd INFOu；
(4) Login stage of business process:
s4.1, the consumer Ru sends a login request to the merchant system Rb and sends an ID to the merchant system Rbub、STubAnd security information such as SI; SI indicates DeIDubAnd PWubSecurity information of the outside;
s4.2, after receiving the login request, the merchant system Rb carries out the stepsID of consumer RuubRetrieving a reserved security token ST from a databaseubAnd auditing is carried out; after the verification is passed, sending a system message MSG to the consumer Ru;
(5) and (3) settlement stage:
s5.1, the consumer Ru sends a settlement request to the merchant system Rb and sends an ID to the merchant system RbupEstablishing a trust relationship between Rb and Rp;
s5.2, after the merchant system Rb receives the settlement request, the ID is sentupForwarding to a payment platform Rp;
s5.3, the payment platform Rp is according to the IDupInquiring the relevant information of the consumer Ru from the database, if the relevant information is not inquired, returning relevant error information, if the relevant information is inquired, generating a random character string S, and sending the S to the merchant system Rb;
s5.4, the merchant system Rb forwards the random character string S to the consumer Ru after receiving the random character string S;
s5.5, after the consumer Ru receives the random character string S, the random character string S utilizes the private key PRK stored locallyuEncrypting the random string S to obtain a security token STupAnd secure token STupSending to the merchant system Rb;
s5.6, after the merchant system Rb receives the security token STupThen forwarding to a payment platform Rp;
s5.7, the payment platform Rp receives the security token STupThereafter, a digital certificate CER of the consumer Ru is requested from the certificate authority CAuVerifying the digital signature of the certification center CA and then receiving the certificate from the CERuPublic key PUK for extracting Ru of consumeru；
S5.8, the payment platform utilizes the public key PUK of the Ru of the consumeruDecrypting a security token STupObtaining S ', if S is equal to S', establishing a TRUST relationship TRUST and sending a system message informing that the verification is successful, and if the verification is failed, sending the system message which passes the verification failure;
s5.9, establishing a trust relationship between the merchant system Rb and the payment platform Rp;
s5.10, the merchant system Rb sends a settlement request to the payment platform Rp and sends settlement information M;
s5.11, the payment platform Rp settles the account to the merchant system Rb;
s5.12, if the settlement is successful, the payment platform Rp returns a settlement successful message to the merchant system Rb;
s5.13, the merchant system Rb returns a settlement success message to the consumer Ru.
2. The method of claim 1, further comprising:
(6) contract maintenance stage:
s6.1, the consumer Ru initiatively initiates a contract maintenance request to the payment platform Rp and sends the contract maintenance request including the ID encrypted by the private key to the payment platform Rpup、STupAnd INFOuThe basic information inside; the contract maintenance is mainly used for modifying related information INFO of the consumer Ruu；
S6.2, after receiving the maintenance contract request, the payment platform Rp conducts auditing, and the audited content comprises information integrity and identifier uniqueness; requesting the certificate authority CA for the digital certificate CER of the consumer Ru after the successful audituAnd extracting public key PUK of consumer Ruu；
S6.3, payment platform Rp uses public key PUK of consumer RuuDecryption INFOuThen using the decrypted INFOuReplace original INFO'u。
3. The method according to claim 1, characterized in that in step S2.2, the audited content includes information integrity and identifier uniqueness.
4. The method according to claim 1, characterized in that in step S3.2, the audited content includes information integrity and identifier uniqueness.
CN201911061547.1A 2019-11-01 2019-11-01 Pure software CAVA identity authentication method based on trusted third party Pending CN110855444A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911061547.1A CN110855444A (en) 2019-11-01 2019-11-01 Pure software CAVA identity authentication method based on trusted third party

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911061547.1A CN110855444A (en) 2019-11-01 2019-11-01 Pure software CAVA identity authentication method based on trusted third party

Publications (1)

Publication Number Publication Date
CN110855444A true CN110855444A (en) 2020-02-28

Family

ID=69598775

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911061547.1A Pending CN110855444A (en) 2019-11-01 2019-11-01 Pure software CAVA identity authentication method based on trusted third party

Country Status (1)

Country Link
CN (1) CN110855444A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114626860A (en) * 2022-05-12 2022-06-14 武汉和悦数字科技有限公司 Dynamic identity identification method and device for online commodity payment

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070288392A1 (en) * 2003-12-31 2007-12-13 Guilin Peng Secure Online Payment System And Online Payment Authentication Method
US20110270763A1 (en) * 2010-04-30 2011-11-03 Tobsc Inc. Methods and apparatus for a financial document clearinghouse and secure delivery network
CN102448061A (en) * 2011-11-18 2012-05-09 王黎明 Method and system for preventing phishing attack on basis of mobile terminal
CN103020825A (en) * 2012-12-05 2013-04-03 福建省派活园科技信息有限公司 Safety payment authentication method based on software client
WO2014053172A1 (en) * 2012-10-03 2014-04-10 Buntinx Bvba Method and system for securely authenticating entities
CN105577612A (en) * 2014-10-11 2016-05-11 中兴通讯股份有限公司 Identity authentication method, third party server, merchant server, and user terminal
CN106330430A (en) * 2016-08-29 2017-01-11 江苏高网信息科技有限公司 Third-party mobile payment method based on NTRU

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070288392A1 (en) * 2003-12-31 2007-12-13 Guilin Peng Secure Online Payment System And Online Payment Authentication Method
US20110270763A1 (en) * 2010-04-30 2011-11-03 Tobsc Inc. Methods and apparatus for a financial document clearinghouse and secure delivery network
CN102448061A (en) * 2011-11-18 2012-05-09 王黎明 Method and system for preventing phishing attack on basis of mobile terminal
WO2014053172A1 (en) * 2012-10-03 2014-04-10 Buntinx Bvba Method and system for securely authenticating entities
CN103020825A (en) * 2012-12-05 2013-04-03 福建省派活园科技信息有限公司 Safety payment authentication method based on software client
CN105577612A (en) * 2014-10-11 2016-05-11 中兴通讯股份有限公司 Identity authentication method, third party server, merchant server, and user terminal
CN106330430A (en) * 2016-08-29 2017-01-11 江苏高网信息科技有限公司 Third-party mobile payment method based on NTRU

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
王亮: "基于信任传递的移动商务虚拟身份认证机制研究", 《中国优秀博硕士学位论文全文数据库(博士)信息科技辑》 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114626860A (en) * 2022-05-12 2022-06-14 武汉和悦数字科技有限公司 Dynamic identity identification method and device for online commodity payment

Similar Documents

Publication Publication Date Title
US11856104B2 (en) Methods for secure credential provisioning
CN109728909B (en) Identity authentication method and system based on USBKey
US9813245B2 (en) Methods for secure cryptogram generation
US8245030B2 (en) Method for authenticating online transactions using a browser
US8533482B2 (en) Method for generating a key pair and transmitting a public key or request file of a certificate in security
US7930542B2 (en) MashSSL: a novel multi party authentication and key exchange mechanism based on SSL
TWI512524B (en) System and method for identifying users
US20080034216A1 (en) Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords
KR101634158B1 (en) Method for authenticating identity and generating share key
JP2011125020A (en) System and method for designing secure client-server communication based on certificateless public key infrastructure
CN103763631A (en) Authentication method, server and television
CN102164033A (en) Method, device and system for preventing services from being attacked
WO2016054905A1 (en) Method for processing data
CN111355591A (en) Block chain account safety management method based on real-name authentication technology
CN110866754A (en) Pure software DPVA (distributed data authentication and privacy infrastructure) identity authentication method based on dynamic password
CN114553441B (en) Electronic contract signing method and system
CN113507372A (en) Bidirectional authentication method for interface request
CN101277186B (en) Method for implementing exterior authentication using asymmetry key algorithm
CN114531243A (en) Alliance chain transaction privacy protection method based on label encryption and zero knowledge certification
JP7209518B2 (en) Communication device, communication method, and communication program
Subpratatsavee et al. Transaction authentication using HMAC-based one-time password and QR code
CN111062029A (en) Multi-factor authentication protocol based on identification password
CN110855444A (en) Pure software CAVA identity authentication method based on trusted third party
CN114389808B (en) OpenID protocol design method based on SM9 blind signature
CN110572257B (en) Identity-based data source identification method and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200228