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

Abstract

The invention discloses a pure software CAVA identity authentication method based on a trusted third party, which pre-verifies the identity authentication request process, and requests that fail the pre-verification will not be processed on the server side, which can effectively resist denial of service attacks. In addition, by introducing a trusted third party to achieve two-way identity authentication, it can effectively resist phishing attacks. On the one hand, the present invention can reduce the computing intensity of both the server and the client, simplify the user authentication and authorization process, and effectively improve the authentication efficiency.

Description

A pure software CAVA identity authentication method based on trusted third party

technical field

The invention belongs to the field of information technology and is applied to the e-commerce industry, in particular to a pure software CAVA identity authentication method based on a trusted third party.

Background technique

The existing two-party identity authentication generally refers to the mutual identity authentication only through the negotiation, information exchange and judgment of the two parties in the transaction. This authentication method does not require the participation of a third party, and the process is simple, but it cannot accurately determine the identities of the two parties. Common two-party authentication mechanisms mainly include the following types.

(1) Single-factor authentication

Single-factor authentication is generally based on passwords. This authentication method is a process in which the verifier enters account and password information, and the verifier performs identity authentication by comparing the input information and the verifier's stored information. . Accounts and passwords are generally reserved when the verifier registers, and these information are encrypted and stored in the verifier's database.

Lamport proposed a one-time password-based authentication scheme in 1981. In this authentication scheme, the verifier realizes the purpose of identity authentication by comparing the password input by the verifier with the password table stored in the verifier server in advance. Subsequently, Shimizu, Hailer, and Sandirigama et al. made improvements in safety, performance, and efficiency based on Lamport's scheme. The advantage of this type of scheme is that it is easier to implement, but the verifier needs to store the user password or password table. Once the database vulnerability on the verifier causes the password to be lost or the rules of the password table to be cracked, the security of the authentication system will be threatened. At the same time, this type of solution is mainly oriented towards one-way authentication and cannot achieve two-way authentication, which is easy to cause counterfeiting and phishing attacks.

Harn et al. proposed a password authentication scheme based on asymmetric key system based on Diffie-Hellman public key encryption technology. This scheme does not require special protection of the information related to the user password on the verifier side, and does not require the participation of the verifier when updating the relevant verification information.

Peyravian and Zunic proposed a lightweight one-way authentication protocol based on digest algorithm, but this protocol is vulnerable to phishing attacks and other security problems. In order to solve the problems in this protocol, Hwang et al. proposed improvement schemes for the Peyravian-Zunic protocol in the literature and Lee et al. Peyravian also proposed an optimization scheme for his own protocol. After that, Zhu et al. proposed an improved protocol based on the Hwang-Yeh protocol, but this improved protocol is lacking in resisting impersonation attacks and key agreement. Islam et al. proposed an improved protocol based on the Hwang-Yeh protocol to solve the above problems.

(2) Multi-factor authentication

There are many problems in password-based single-factor authentication. For example, user passwords are stored in the authenticator server, and the technical level and awareness of authenticators vary, resulting in data security risks and user information leakage. Attackers can use stealing, analysis, decryption and even "credential stuffing" to attack. In addition, password-based single-factor authentication is one-way, the server can authenticate the user's identity, but the user cannot authenticate the server's identity, which makes phishing and counterfeiting possible.

A smart card is an information device that is not easy to counterfeit. It is generally issued by an authenticator and supports high-strength encryption. Using smart cards and passwords to jointly implement identity authentication can solve the above problems to a certain extent. In 1991, Chang and Wu proposed a two-factor authentication protocol based on smart cards and passwords. Lee and Chang proposed an authentication system based on user identity and distributed key for the first time, but this protocol is weak against counterfeiting attacks. Tsuar and Wu et al. proposed an identity authentication protocol based on asymmetric encryption algorithm RSA. Li and Lin et al. proposed an identity authentication protocol based on neural network, but this protocol has a large load on hardware. Lin and Hwang et al. improved this problem. Chang and Lee et al. proposed a key generation algorithm without a preset table, but the key generated by this algorithm is not dynamic and vulnerable to counterfeiting attacks. In 2009, Liao and Wang proposed an authentication protocol based on dynamic identification codes. On this basis, Hsiang and Shih proposed an improved scheme using dynamic identification codes instead of static identification codes. Since then, Shao and Chin et al. and Wang and Ma et al. have made further improvements on security and lightweight issues, respectively. In 2011, Wen and Li pointed out the possibility of impersonation and password guessing attacks in the Wang-Ma protocol, and proposed an improved dynamic key agreement authentication protocol based on the Wang-Ma protocol. It is very efficient to perform calculations using functions, but at the same time there are internal security risks and may be subject to counterfeiting or phishing attacks.

(3) Challenge response authentication

Challenge-Response authentication is a typical zero-knowledge proof authentication method. In current mobile commerce, the identity authentication mechanism combining password authentication and challenge-response authentication is widely used.

The principle of challenge-response authentication is that the verifier server will send a random "challenge" message to the verifier each time it is authenticated. According to the response result, the person verifies whether the identity of the verified person is legal. The authentication process is shown in Figure 2.

Since the challenge-response authentication scheme is initiated irregularly by the verifier, if the verifier frequently requests authentication, it will bring great resource consumption to the authentication server, network service provider and client. At the same time, due to the fact that the authentication scheme has many manual participation processes, and the information transmission and reception have a great influence on the mobile communication network and the supplier, delays may be caused. The challenge-response authentication scheme is more suitable for the identity authentication process in which only two parties participate.

SUMMARY OF THE INVENTION

In view of the deficiencies of the prior art, the present invention aims to provide a pure software CAVA identity authentication method based on a trusted third party.

In order to achieve the above object, the present invention adopts the following technical solutions:

A pure software CAVA identity authentication method based on a trusted third party, comprising the following steps:

(1) Digital certificate application stage:

S1.1, the consumer Ru and the payment platform Rp respectively send a request for applying for a digital certificate to the certification center CA;

S1.2. After the certification center CA examines the request for a digital certificate, it issues digital certificates CER _u and CER _p for the consumer Ru and the payment platform Rp respectively. The digital certificates contain the basic information INFO and the public key of the identity authentication participants. Digital Signature DS of PUK and Certification Authority CA;

(2) Contract initialization phase:

S2.1, the consumer Ru sends a contract establishment request to the payment platform Rp, and sends basic information including ID _up and INFO _u to the payment platform Rp; where ID _up represents the identity identifier of the consumer Ru in the payment platform Rp ID _up ; INFO _u represents the non-security information of consumer Ru;

S2.2. After the payment platform Rp receives the request to establish a contract, it will first review it;

S2.3. After passing the review, the payment platform Rp sends a review success message to the consumer Ru;

S2.4. After receiving the success message, the consumer Ru and the payment platform Rp request the certification center CA for the digital certificates CER _p and CER _u of the other party respectively, CER _p represents the digital certificate of the payment platform Rp, and CER _u represents the digital certificate of the consumer Ru Digital certificate; since the digital certificate contains the real identity information of the consumer Ru and the payment platform Rp, and is guaranteed by a trusted third party, namely the certification center CA, through digital signatures, the consumer Ru and the payment platform Rp can pass the digital certificate to the two-way confirm the identity of the other party;

S2.5. After receiving the digital certificate request from the consumer Ru and the payment platform Rp, the certification center extracts the digital certificates CER _p and CER _u ;

S2.6, the certification center CA sends the digital certificates CER _p and CER _u to the consumer Ru and the payment platform Rp respectively;

S2.7, after the consumer Ru and the payment platform Rp receive the digital certificate of the other party, verify the digital signature DS of the certification center CA and confirm the true identity of the other party, the contract is reached, and the payment platform Rp stores INFO _u ;

(3) The registration stage of the business process:

S3.1, the consumer Ru sends a registration request to the merchant system Rb, and sends basic information including ID _ub and INFO _u to the merchant system Rb; ID _ub represents the identity identifier of the consumer Ru in the merchant system Rb;

S3.2. After receiving the registration request, the merchant system Rb will review it first; after passing the review, it will send the system message MSG to the consumer Ru;

S3.3. After receiving the system message MSG, the consumer Ru passes the password PW _ub set by itself through a hash algorithm to obtain the security token ST _ub and sends the security token ST _ub to Rb;

S3.4. After the merchant system Rb receives the security token ST _ub , it stores ST _ub and INFO _u ;

(4) The login stage of the business process:

S4.1. Consumer Ru sends a login request to the merchant system Rb, and sends security information such as ID _ub , ST _ub and SI to the merchant system Rb; SI represents security information other than ID _ub and PW _ub ;

S4.2. After receiving the login request, the merchant system Rb retrieves the reserved security token ST _ub from the database according to the ID _ub of the consumer Ru and conducts audit; after passing the audit, it sends the system message MSG to the consumer Ru ;

(5) Settlement stage:

S5.1, the consumer Ru sends a settlement request to the merchant system Rb, and sends ID _up to the merchant system Rb for establishing a trust relationship between Rb and Rp;

S5.2. After receiving the settlement request, the merchant system Rb forwards the ID _up to the payment platform Rp;

S5.3. The payment platform Rp queries the relevant information of the consumer Ru from the database according to the ID _up . If it is not queried, it will return the relevant error information. If it is queried, it will generate a random string S, and send S to the merchant system Rb ;

S5.4. After receiving the random string S, the merchant system Rb forwards it to the consumer Ru;

S5.5. After receiving the random string S, the consumer Ru encrypts the random string S with the private key PRK _u stored locally to obtain a security token ST _up and the security token ST _up Sent to the merchant system Rb;

S5.6. After receiving the security token ST _up , the merchant system Rb forwards it to the payment platform Rp;

S5.7. After receiving the security token ST _up , the payment platform Rp requests the certification center CA for the digital certificate CER _u of the consumer Ru, and after verifying the digital signature of the certification center CA, extracts the public key PUK of the consumer Ru from the CER _{u u} ;

S5.8. The payment platform uses the public key PUK _u of the consumer Ru to decrypt the security token ST _up and obtain S'. If S=S', the trust relationship TRUST is established and a system message notifying that the verification is successful is sent. If the verification fails, the Send system messages that fail authentication;

S5.9, the establishment of trust relationship between the merchant system Rb and the payment platform Rp;

S5.10, the merchant system Rb initiates a settlement request to the payment platform Rp and sends settlement information M;

S5.11. The payment platform Rp settles with the merchant system Rb;

S5.12. If the settlement is successful, the payment platform Rp returns a settlement success 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 includes:

(6) Contract maintenance stage:

S6.1. Consumer Ru actively initiates a maintenance contract request to payment platform Rp, and sends basic information including ID _up , ST _up and INFO _u encrypted with private key to payment platform Rp; contract maintenance is mainly used for modification Information INFO _u of consumer Ru;

S6.2. After the payment platform Rp receives the maintenance contract request, it first conducts an audit, and the audit content includes information integrity and identifier uniqueness; after the audit is successful, it requests the certification center CA for the digital certificate CER _u of the consumer Ru and extracts it the public key PUK _u of the consumer Ru;

S6.3. After the payment platform Rp decrypts the INFO _u with the public key PUK _u of the consumer Ru, it replaces the original INFO' _{u with the decrypted 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 beneficial effects of the present invention are:

(1) Resistant to denial of service attacks

The present invention verifies the identity authentication request process in advance, and requests that fail to pass the pre-verification will not be processed on the server side, which can effectively resist denial of service attacks.

(2) Resist phishing attacks

The invention introduces a trusted third party, realizes two-way identity authentication, and can effectively resist phishing attacks.

(3) Certification efficiency

On the one hand, the present invention can reduce the computing intensity of both the server and the client, simplify the user authentication and authorization process, and effectively improve the authentication efficiency.

(4) Anti-DoS and dictionary attacks

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. That is: after the consumer Ru completes the business process, he makes a settlement request to the merchant system Rb. After receiving the request, Rb sends the unique identifier ID _up of Ru in the payment platform Rp to Rp, and Rp will query the database for ID _up . Authenticity re-establishes connection. In this process, firstly, Ru cannot actively send settlement requests, and the attackers cannot actively send settlement requests, so it is difficult for attackers to achieve active anonymous requests, reducing the possibility of DoS attacks and dictionary attacks.

(5) Resist impersonation and replay attacks

In the present invention, every time Ru makes a login request, Rp will send the random string S to the client. After receiving the request, Rp will ask Rb to forward the random string S to Ru. After receiving S, Ru needs to use the private The key PRK _u encrypts S, and sends the encrypted security token ST _up to Rp. Rp uses the consumer public key PUK _u stored in the contract establishment stage to decrypt, and compares the decrypted S' and S . This random string S is destroyed every time the user successfully logs in. Based on the above process, the following conclusions can be drawn.

a) The key pair (PRK _u , PUK _u ) of the consumer Ru is only transmitted in the contract establishment phase, and the merchant system Rb does not participate in this phase, so it is impossible for Rb to obtain the key;

b) Since the string S in each settlement process is randomly generated, ST _up (S encrypted with PRK _u ) is also unique, and the merchant system Rb cannot use the ST _up obtained in this settlement process for subsequent settlements .

Based on the above analysis, this scheme can effectively prevent impersonation and replay attacks.

(6) Anti-transaction denial

Based on the workflow of the present invention, the following conclusions can be drawn.

a) Consumer Ru's private key PRK _u belongs to Ru's exclusive information and is recognized by both Ru and Rp during the contract establishment stage. Ru uses PRK _u to digitally sign the random string S during the settlement process. According to the basic principles of symmetric encryption and digital signature, this process is non-repudiation.

b) In each key process of the present invention, there is a log storage link, and the log can guarantee the authenticity of historical transactions.

Based on the above analysis, Ru cannot deny the authenticity of the transaction that has occurred under normal circumstances, that is, the present invention can effectively prevent transaction denial.

Description of drawings

1 is a schematic diagram of the constituent elements of an identity authentication system in the prior art;

2 is a schematic diagram of a challenge-response authentication process in an existing identity authentication technology;

3 is a schematic flowchart of a digital certificate application stage in an embodiment of the present invention;

4 is a schematic flowchart of a contract initialization phase in an embodiment of the present invention;

5 is a schematic flowchart of a registration stage of a business process in an embodiment of the present invention;

6 is a schematic flowchart of a login stage of a business process in an embodiment of the present invention;

7 is a schematic flowchart of a settlement stage in an embodiment of the present invention;

FIG. 8 is a schematic flowchart of a contract maintenance phase in an embodiment of the present invention.

Detailed ways

The present invention will be further described below in conjunction with the accompanying drawings. It should be noted that the present embodiment takes the technical solution as the premise, and provides a detailed implementation manner and a specific operation process, but the protection scope of the present invention is not limited to the present invention. Example.

1. The following is a brief description of some technical terms in this field

1) Password and encryption algorithm

Cryptography is a branch of information theory that handles all aspects of secure messaging, including authentication, digital signatures, and key management. In simple terms, encryption is a process that rearranges plaintext information in a certain way to make it incomprehensible ciphertext information. The recipient of the information restores the ciphertext information to plaintext information through the opposite process and then uses it. We can explain the encryption and decryption process with the following definitions and procedures.

Definition: Encryption Algorithm

The information in the encryption and decryption process is defined as follows:

(1) M _p : the original plaintext information of the information sender;

(2) K: the key used by the information sender to encrypt _Mp ;

(3) M _c : the ciphertext obtained after the information sender encrypts M _p ;

(4) M _c ': cipher text received by the information receiver;

(5) _K ': the key used by the information receiver to decrypt Mc';

(6) M _p ': plaintext information obtained after decrypting M _c '.

Then, the encryption algorithm can be defined as:

E:(M _p +K)→M _c

The decryption algorithm can be defined as:

E':(M _c '+K')→M _p '

2) Identity authentication

Identity Authentication is the process of verifying the legality of the identity of business participants, and it is the basis for the operation of the entire business activity. The basic principle of identity authentication is to verify the relevant information of the authenticated to realize identity confirmation. With the rapid development of e-commerce, especially mobile commerce, authenticating the identities of business participants and ensuring the security of all parties is becoming one of the most critical processes in the mobile commerce process. Identity authentication technology can be divided into one-way authentication and two-way authentication according to the different authentication levels and authentication entities, and its characteristics and applicable environment are shown in Table 1.

Table 1 One-way and two-way authentication

A common identity authentication system includes the following parts: identity authentication protocol, business participants, authentication information and attackers, as shown in Figure 1.

According to the above basic elements, we can describe the basic functions that the identity authentication system should have. As shown in table 2. Generally speaking, identity authentication schemes can be divided into two categories: simple identity authentication schemes and high-strength identity authentication schemes. The identity authentication information of the simple identity authentication scheme generally only contains key information such as account numbers and passwords, and the information is generally transmitted in an unencrypted form. However, non-encrypted information is easily obtained illegally. The general solution is to process the information through a hash function (such as MD5 or SHA) or use dynamic passwords (OTP). Using these schemes, even if the plaintext of the information is stolen, it cannot be Derive the original authentication information. High-strength identity authentication schemes generally use a compound encryption mechanism to prevent sensitive data from being illegally obtained and used during the authentication process. For example, the Kerberos protocol is a widely used strong authentication scheme. Emerging high-intensity authentication schemes integrate technologies such as trusted third parties, challenge/response, smart cards and even biometrics to achieve higher-intensity authentication. Several common authentication schemes are listed below, and their characteristics and application environments are discussed.

Table 2 Main functions of the identity authentication system

3) Dynamic password

Dynamic passwords are also called one-time passwords (One Time Password). The secret information used by the dynamic password is different in each transaction process. Even if the attacker obtains the security information in a certain transaction process by some means, it cannot be used for the next transaction.

The basic principle of dynamic passwords is that the authenticated party first makes an authentication request, and the authenticator generates a dynamic information according to the authentication request. This dynamic information can be any unique information that cannot be inferred, such as random numbers or timestamps, or it can be fixed in The unique information formed by calculation or combination on the basis of information, such as the value obtained by dynamic encryption or digest algorithm.

Due to the uniqueness and inconsistency of dynamic passwords, the identity authentication technology based on dynamic passwords 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 the business system itself. Typical dynamic passwords are shown in Table 3.

Table 3 Typical dynamic passwords

Compared with the traditional static password authentication technology, the dynamic password has the characteristics described in Table 4:

Table 4 Characteristics of dynamic passwords

2. Method description

The parameters and their symbols used in the method description are shown in Table 5:

Table 5 Symbol description of this technical solution

The method includes the following steps:

(1) The digital certificate application stage, as shown in Figure 3:

S1.1, the consumer Ru and the payment platform Rp respectively send a request for applying for a digital certificate to the certification center CA;

S1.2. After the certification center CA examines the request for a digital certificate, it issues digital certificates CER _u and CER _p for the consumer Ru and the payment platform Rp respectively. The digital certificates contain the basic information INFO and the public key of the identity authentication participants. Digital Signature DS of PUK and Certification Authority CA;

(2) Contract initialization phase, as shown in Figure 4:

S2.1, the consumer Ru sends a contract establishment request to the payment platform Rp, and sends basic information including ID _up and INFO _u to the payment platform Rp; where ID _up represents the identity identifier of the consumer Ru in the payment platform Rp ID _up ; INFO _u represents the non-security information of the consumer Ru; generally, the non-security information includes nickname, gender, interest, points and the like.

S2.2. After receiving the request to establish a contract, the payment platform Rp will conduct an audit first, and the audit content includes information integrity and identifier uniqueness;

S2.3. After passing the review, the payment platform Rp sends a review success message to the consumer Ru;

S2.4. After receiving the success message, the consumer Ru and the payment platform Rp request the certification center CA for the digital certificates CER _p and CER _u of the other party respectively, CER _p represents the digital certificate of the payment platform Rp, and CER _u represents the digital certificate of the consumer Ru Digital certificate; since the digital certificate contains the real identity information of the consumer Ru and the payment platform Rp, and is guaranteed by a trusted third party, namely the certification center CA, through digital signatures, the consumer Ru and the payment platform Rp can pass the digital certificate to the two-way confirm the identity of the other party;

S2.5. After receiving the digital certificate request from the consumer Ru and the payment platform Rp, the certification center extracts the digital certificates CER _p and CER _u ;

S2.6, the certification center CA sends the digital certificates CER _p and CER _u to the consumer Ru and the payment platform Rp respectively;

S2.7. After the consumer Ru and the payment platform Rp receive the digital certificate of the other party, they verify the digital signature DS of the certification center CA and confirm the true identity of the other party. The contract is reached, and the payment platform Rp stores INFO _u .

(3) The registration stage of the business process, as shown in Figure 5:

S3.1, the consumer Ru sends a registration request to the merchant system Rb, and sends basic information including ID _ub and INFO _u to the merchant system Rb; ID _ub represents the identity identifier of the consumer Ru in the merchant system Rb;

S3.2. After receiving the registration request, the merchant system Rb will conduct an audit first, and the audit content includes information integrity and identifier uniqueness; after passing the audit, it will send the system message MSG to the consumer Ru;

S3.3. After receiving the system message MSG, the consumer Ru passes the password PW _ub set by itself through a hash algorithm to obtain the security token ST _ub and sends the security token ST _ub to Rb;

ST _ub = HASH(PW _ub );

S3.4. After the merchant system Rb receives the security token ST _ub , it stores ST _ub and INFO _u ;

(4) The login stage of the business process, as shown in Figure 6:

S4.1. Consumer Ru sends a login request to the merchant system Rb, and sends security information such as ID _ub , ST _ub and SI to the merchant system Rb; SI represents security information other than ID _ub and PW _ub , such as verification code and challenge/response information;

S4.2. After receiving the login request, the merchant system Rb retrieves the reserved security token ST _ub from the database according to the ID _ub of the consumer Ru and conducts an audit. The audit content includes calculating and judging the ST in the user's login request. Whether the security token ST _ub in the database is consistent with _ub ; after passing the audit, send the system message MSG to the consumer Ru;

(5) Settlement stage, as shown in Figure 7:

S5.1, the consumer Ru sends a settlement request to the merchant system Rb, and sends ID _up to the merchant system Rb for establishing a trust relationship between Rb and Rp;

S5.2. After receiving the settlement request, the merchant system Rb forwards the ID _up to the payment platform Rp;

S5.3. The payment platform Rp queries the relevant information of the consumer Ru from the database according to the ID _up . If it is not queried, it will return the relevant error information. If it is queried, it will generate a random string S, and send S to the merchant system Rb ;

S5.4. After receiving the random string S, the merchant system Rb forwards it to the consumer Ru;

S5.5. After receiving the random string S, the consumer Ru encrypts the random string S with the private key PRK _u stored locally to obtain a security token ST _up and the security token ST _up Sent to the merchant system Rb;

_STup =EC(S) _PRKu ;

EC(S) _PRKu means to encrypt the random string S with the private key PRK _u ;

S5.6. After receiving the security token ST _up , the merchant system Rb forwards it to the payment platform Rp;

S5.7. After receiving the security token ST _up , the payment platform Rp requests the certification center CA for the digital certificate CER _u of the consumer Ru, and after verifying the digital signature of the certification center CA, extracts the public key PUK of the consumer Ru from the CER _{u u} ;

S5.8. The payment platform uses the public key PUK _u of the consumer Ru to decrypt the security token ST _up and obtain S'. If S=S', the trust relationship TRUST is established and a system message notifying that the verification is successful is sent. If the verification fails, the Send system messages that fail authentication;

S'=DC( _STup ) _PUKu ;

DC(ST _up ) _PUK means using the public key PUK _u to decrypt ST _up ;

S5.9, the establishment of trust relationship between the merchant system Rb and the payment platform Rp;

TRUST=IsTrue(S=S');

IsTrue() represents a function that judges whether a condition is true;

S5.10, the merchant system Rb initiates a settlement request to the payment platform Rp and sends settlement information M;

S5.11. The payment platform Rp settles with the merchant system Rb;

S5.12. If the settlement is successful, the payment platform Rp returns a settlement success message to the merchant system Rb;

S5.13, the merchant system Rb returns a settlement success message to the consumer Ru.

(6) Contract maintenance stage, as shown in Figure 8:

S6.1. Consumer Ru actively initiates a maintenance contract request to payment platform Rp, and sends basic information including ID _up , ST _up and INFO _u encrypted with private key to payment platform Rp; the purpose of contract maintenance is generally to Modify the relevant information of consumer Ru INFO _u ;

S6.2. After the payment platform Rp receives the maintenance contract request, it first conducts an audit, and the audit content includes information integrity and identifier uniqueness; after the audit is successful, it requests the certification center CA for the digital certificate CER _u of the consumer Ru and extracts it the public key PUK _u of the consumer Ru;

INFO _u =new(INFO _u );

S6.3. After the payment platform Rp decrypts the INFO _u with the public key PUK _u of the consumer Ru, it replaces the original INFO' _{u with the decrypted INFO u :}

INFO _u =DC(new(INFO _u )) _PUK ;

INFO' _u =INFO _u .

Compared with the prior art, the method of this embodiment mainly has the following advantages:

(1) Resistant to denial of service attacks

The method of this embodiment performs pre-verification on the identity authentication request process, and requests that fail the pre-verification will not be processed on the server side, which can effectively resist denial of service attacks.

(2) Resist phishing attacks

The method of this embodiment introduces a trusted third party, realizes two-way identity authentication, and can effectively resist phishing attacks.

(3) Certification efficiency

On the one hand, the method of this embodiment can reduce the computational intensity of both the server and the client, simplify the user authentication and authorization process, and effectively improve the authentication efficiency.

(4) Anti-DoS and dictionary attacks

In this solution, the settlement request of the consumer Ru is not actively triggered by Ru, but passively triggered by the information sent by Rp. That is: after the consumer Ru completes the business process, he makes a settlement request to the merchant system Rb. After receiving the request, Rb sends the unique identifier ID _up of Ru in the payment platform Rp to Rp, and Rp will query the database for ID _up . Authenticity re-establishes connection. In this process, firstly, Ru cannot actively send settlement requests, and the attackers cannot actively send settlement requests, so it is difficult for attackers to achieve active anonymous requests, reducing the possibility of DoS attacks and dictionary attacks.

(5) Resist impersonation and replay attacks

In this solution, Rp will send a random string S to the client every time Ru makes a login request. After receiving the request, Rp will ask Rb to forward the random string S to Ru. After receiving S, Ru needs to use the private The key PRK _u encrypts S, and sends the encrypted security token ST _up to Rp. Rp uses the consumer public key PUK _u stored in the contract establishment stage to decrypt, and compares the decrypted S' and S . This random string S is destroyed every time the user successfully logs in. Based on the above process, the following conclusions can be drawn.

a) The key pair (PRK _u , PUK _u ) of the consumer Ru is only transmitted in the contract establishment phase, and the merchant system Rb does not participate in this phase, so it is impossible for Rb to obtain the key;

b) Since the string S in each settlement process is randomly generated, ST _up (S encrypted with PRK _u ) is also unique, and the merchant system Rb cannot use the ST _up obtained in this settlement process for subsequent settlements .

Based on the above analysis, this scheme can effectively prevent impersonation and replay attacks.

(6) Anti-transaction denial

Based on the workflow of this scheme, the following conclusions can be drawn.

a) Consumer Ru's private key PRK _u belongs to Ru's exclusive information and is recognized by both Ru and Rp during the contract establishment stage. Ru uses PRK _u to digitally sign the random string S during the settlement process. According to the basic principles of symmetric encryption and digital signature, this process is non-repudiation.

b) In each key process of this scheme, there is a log storage link, and the log can guarantee the authenticity of historical transactions.

Based on the above analysis, Ru cannot deny the authenticity of the transaction that has occurred under normal circumstances, that is, this solution can effectively prevent transaction denial.

For those skilled in the art, various corresponding changes and deformations can be given according to the above technical solutions and concepts, and all these changes and deformations should be included within the protection scope of the claims 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 Rp_uAnd CER_pThe 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 Rp_upAnd INFO_uThe basic information inside; wherein the ID_upIdentity identifier ID representing consumer Ru in payment platform Rp_up；INFO_uNon-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 CA_pAnd CER_u，CER_pDigital certificate, CER, representing a payment platform Rp_uA 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 CER_pAnd CER_u；

S2.6, the certification center CA sends digital certificates CER to the consumers Ru and the payment platform Rp respectively_pAnd CER_u；

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 INFO_u；

(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 Rb_ubAnd INFO_uThe basic information inside; ID_ubAn 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 itself_ubObtaining a security token ST through a hash algorithm for 1 time_ubAnd secure token ST_ubSending the data to Rb;

s3.4, receiving the security token ST by the merchant system Rb_ubThen, ST is stored_ubAnd INFO_u；

(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 Rb_ub、ST_ubAnd security information such as SI; SI indicates DeID_ubAnd PW_ubSecurity information of the outside;

s4.2, after receiving the login request, the merchant system Rb carries out the stepsID of consumer Ru_ubRetrieving a reserved security token ST from a database_ubAnd 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 Rb_upEstablishing a trust relationship between Rb and Rp;

s5.2, after the merchant system Rb receives the settlement request, the ID is sent_upForwarding to a payment platform Rp;

s5.3, the payment platform Rp is according to the ID_upInquiring 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 locally_uEncrypting the random string S to obtain a security token ST_upAnd secure token ST_upSending to the merchant system Rb;

s5.6, after the merchant system Rb receives the security token ST_upThen forwarding to a payment platform Rp;

s5.7, the payment platform Rp receives the security token ST_upThereafter, a digital certificate CER of the consumer Ru is requested from the certificate authority CA_uVerifying the digital signature of the certification center CA and then receiving the certificate from the CER_uPublic key PUK for extracting Ru of consumer_u；

S5.8, the payment platform utilizes the public key PUK of the Ru of the consumer_uDecrypting a security token ST_upObtaining 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 Rp_up、ST_upAnd INFO_uThe basic information inside; the contract maintenance is mainly used for modifying related information INFO of the consumer Ru_u；

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 audit_uAnd extracting public key PUK of consumer Ru_u；

S6.3, payment platform Rp uses public key PUK of consumer Ru_uDecryption INFO_uThen using the decrypted INFO_uReplace 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.

Images