A resource access method based on OAuth2.0 token security enhancement

Abstract

The application relates to an OAuth2.0-based token security-enhanced resource access method applied to a server, which comprises the following steps: when an authorization request initiated by a client is received, an authorization code is acquired and returned to the client; the authorization request initiated by the client is triggered when a user applies for accessing the client; a token application request proposed by the client based on the authorization code is received, and an initial access token is generated if the authorization code is correct; a preset encryption algorithm corresponding to a token security vulnerability is selected, a key pair containing a public key and a private key is acquired; the initial access token is digitally signed by using the private key, a generated digital signature is attached to a preset position of the initial access token, a target access token is acquired, and the target access token is sent to the client, so that the client verifies the digital signature based on the public key; if the verification is successful, the target access token is considered to be safe, and the target access token is attached to an authorization request to request to access a to-be-accessed resource owned by a user.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network security and identity verification, and particularly to a token security enhanced resource access method based on OAuth2.0. BACKGROUND

[0002] With the rise of Web2.0, users began to share data between multiple websites and services, and this data sharing demand prompted developers to find a safe and reliable method to manage user authorization. Thus, the OAuth protocol was born, first OAuth1.0 version; OAuth1.0, although it solves part of the authorization problem, but its shortcomings are also obvious: the signature and encryption process is complex, and it is difficult to develop and implement, and not easy to extend; in order to correct these shortcomings, OAuth2.0 emerged.

[0003] OAuth2.0 has a more simplified development process, supports multiple authorization methods, enhanced security, wide applicability, strong scalability compared to OAuth1.0, and is supported by the community and widely adopted. OAuth2.0 design is more intuitive, reducing the cumbersome signature and encryption steps, making it easier for developers to implement and integrate; OAuth2.0 provides authorization code mode, simplified mode, password mode and client credential mode, flexible to adapt to different application scenarios, supporting multiple authorization methods; through the correct implementation and configuration, such as using HTTPS transmission and managing token life cycle, OAuth2.0 can provide higher security; applicable to various types of applications, including web applications, mobile applications, desktop applications and server-side applications, with strong universality; allows developers to extend and customize according to needs, to meet the needs of specific business scenarios. OAuth2.0 has become an industry standard protocol, widely adopted by many well-known platforms and services, with strong community support and rich documentation; through these improvements, OAuth2.0 has become the preferred standard for identity verification and authorization in modern Internet environments.

[0004] However, the existing OAuth2.0 protocol implementation is complex, has no authentication measures, lacks encryption mechanisms, has high token leakage risk, has difficult refresh token management, faces hidden dangers in cross-domain requests, has trust problems with clients, and affects user experience. In the classic OAuth2.0 architecture, the transmission process of the authorization code and the token usually occurs in a non-secure environment, which is vulnerable to various security threats. In particular, in the authorization code mode, the transmission of the authorization code between the client and the authorization server is easily eavesdropped or tampered with, resulting in the unauthorized use or forgery of the authorization code. Attackers can obtain the authorization code through man-in-the-middle attacks, phishing websites, and other means, and use it to generate access tokens, thereby achieving unauthorized access to resources. This security risk poses a serious threat to user data and system security. In addition, if the authorization server's authentication mechanism is not strict, attackers can impersonate the authorization server and trick users into sending authorization codes to fake servers, further exacerbating security risks. In a highly dynamic and complex network environment, how to ensure the secure transmission of authorization codes and tokens and the authenticity verification of the authorization server has become a pressing problem. SUMMARY

[0005] To this end, the technical problem to be solved by the present application is to overcome the problem of token leakage due to the lack of authentication measures and encryption mechanisms in the existing technology based on the OAuth2.0 protocol, which poses a security risk to users.

[0006] To solve the above technical problems, the present application provides a resource access method based on OAuth2.0 token security enhancement, applied to a server, comprising:

[0007] When receiving an authorization request initiated by a client, an authorization code is obtained and returned to the client; the client-initiated authorization request is triggered when a user applies to access the client;

[0008] Receiving a token application request based on the authorization code from the client, if the authorization code is verified correctly, an initial access token is generated;

[0009] According to the token security vulnerability, a corresponding preset encryption algorithm is selected; based on the preset encryption algorithm, a key pair containing a public key and a private key is obtained;

[0010] Using the private key, the initial access token is digitally signed, and the generated digital signature is attached to the preset position of the initial access token to obtain a target access token;

[0011] The target access token is sent to the client, so that the client can verify the digital signature in the target access token based on the public key and using the preset encryption algorithm, if the verification is successful, it is considered that the target access token is secure, and the target access token is attached to the authorization request to request access to the resources owned by the user.

[0012] Preferably, the selecting the corresponding preset encryption algorithm according to the token security vulnerability comprises: when the token security vulnerability comprises a man-in-the-middle attack and a replay attack, selecting an elliptic curve public key cryptography algorithm SM2 as the preset encryption algorithm.

[0013] Based on the elliptic curve public key cryptography algorithm SM2, a key pair comprising a public key and a private key is generated by using SM2.KeyGen(λ);

[0014] Based on SM2.Sign(m), the initial access token is digitally signed by using the private key, and the generated digital signature is attached to a preset position of the initial access token to obtain a target access token;

[0015] The target access token is sent to the client, so that the client verifies the digital signature in the target access token based on the public key by using the elliptic curve public key cryptography algorithm SM2 to obtain a Boolean value, and if the Boolean value is True, it is considered that the target access token is secure, and the target access token is attached to the authorization request to request access to the resource owned by the user.

[0016] Preferably, the generating the key pair comprising the public key and the private key by using SM2.KeyGen(λ) comprises:

[0017] A preset elliptic curve E is an elliptic curve defined on a finite field F p , and for a given security parameter λ, a, b, and G = (x G , y G ) are selected, a and b are equation parameters of the elliptic curve, G is a q-order base point on the elliptic curve E, and (x G , y G ) is the coordinate of the base point.

[0018] The private key is randomly generated by using an SM3 hash function and a random number generator with the server as the signer, and is represented as: sk A = x, x ∈ [1, q-1], and q represents the order of the elliptic curve E;

[0019] Based on the private key, the corresponding public key is calculated by using the preset elliptic curve and the base point, and is represented as: pk A = xG = (x A , y A ).

[0020] Preferably, the generating the target access token by digitally signing the initial access token based on SM2.Sign(m) and by using the private key comprises:

[0021] S41: based on the to-be-accessed resource m, obtain a length of entlen A bit signer identification ID A , and convert it into two bytes to obtain two-byte identification ENTL A ;

[0022] S42: the server calculates the identity identification, denoted as: Z A = H 256 (ENTL A || ID A || a || b || x G || y G || x A || y A );

[0023] S43: select a random number k, multiply it with the base point to obtain the private key kG = (x1, y1);

[0024] S44: using the SM3 hash function, calculate the hash value of the identity identification Z A , the to-be-accessed resource m, and the x-coordinate x1 of the private key, denoted as: r = (e + x1) mod q, e = H v (Z A || m);

[0025] S45: if the hash value r satisfies r = 0 or r = q-k, return to step S43 to reselect the random number k, until the hash value r satisfies r ≠ 0 and r ≠ q-k, then calculate the signature value, denoted as: s = (1 + x) -1 (k-rx) mod q;

[0026] S46: if the signature value s = 0, return to step S43 to reselect the random number k, until the signature value s ≠ 0,

[0027] S47: append the signature value to the header position of the initial access token to obtain the target access token.

[0028] Preferably, the target access token is sent to the client, so that the client verifies the digital signature in the target access token based on the public key using the elliptic curve public key cryptography algorithm SM2 to obtain a Boolean value, if the Boolean value is True, it is considered that the target access token is safe, and the target access token is appended to the authorization request to request access to the to-be-accessed resource owned by the user, including:

[0029] The client receives the target access token and the public key;

[0030] Verify whether the digital signature in the target access token is correct using SM2.Verify(m', σ'), including:

[0031] For the to-be-visited resource m' to be verified for the digital signature, the signature content σ'=(r', s') is obtained, if r', s'=0, the verification fails;

[0032] If r', s'≠0, e'=H v (Z A ||m') is calculated, t=(r'+s')mod q, if t=0, the verification fails;

[0033] If t≠0, (x1', x2')=s'G+tX is calculated, R=(e'+x1')mod||q, if R=r', the verification passes, and 1 is output, otherwise the verification fails, and 0 is output;

[0034] If the verification succeeds, the target access token is considered to be safe, and the target access token is attached to the authorization request to request access to the to-be-visited resource owned by the user.

[0035] Wherein, m' represents the to-be-visited resource to be verified for the digital signature, σ' represents the signature content, including two parts r' and s', and is represented as σ'=(r', s').

[0036] Preferably, the corresponding preset encryption algorithm is selected according to the token security vulnerability, including when the token security vulnerability includes quantum computing threat, the lattice signature algorithm is taken as the preset encryption algorithm:

[0037] Based on the lattice signature algorithm, the public parameter is generated by using Setup(λ)→pp; based on the public parameter, the key pair including a public key and a private key is generated by using KeyGen(pp)→(pk, sk);

[0038] Based on Sign(m, pk)→sig, the initial access token is digitally signed by using the private key, the generated digital signature is attached to the preset position of the initial access token, and the target access token is obtained;

[0039] The target access token is sent to the client, so that the client verifies the digital signature in the target access token based on the public key by using the lattice signature algorithm Verify(pk, m, sig)→0 / 1, if the verification matches, the target access token is considered to be safe, and the target access token is attached to the authorization request to request access to the to-be-visited resource owned by the user.

[0040] Preferably, the public parameter is generated by using Setup(λ)→pp based on the lattice signature algorithm, including:

[0041] A preset positive integer d, ω, κ, k≤n, a prime number q is randomly selected, q=2k+1mod4k and

[0042] calculate: m2←d κ , m←m1+m2;

[0043] Randomly select a positive integer m3, let calculate

[0044] Select a positive integer t and calculate:

[0045]

[0046] Get the common parameters: pp = (D; g; λ, n, d, m1, m2, m3, q, ω, κ, σ, σ2, σ1);

[0047] Among them, τ is the set S bin An element in Represented in the set of integers Random sampling in, r represents the set Any element in, n represents a natural number, D represents the element from the set The matrix is ​​randomly selected uniformly in .

[0048] Preferably, the generating of a key pair including a public key and a private key by using KeyGen(pp)→(pk,sk) based on the public parameters comprises:

[0049] Based on common parameters, select from:

[0050] Use KeyGen(pp)→(pk,sk) to obtain the public key and private key, which are expressed as: pk=(A,B,u), sk=R;

[0051] Among them, A represents the Randomly select the matrix uniformly, R represents the matrix from the set The matrix is ​​randomly selected uniformly in .

[0052] Preferably, the method of digitally signing the initial access token using a private key based on Sign(m,pk)→sig, appending the generated digital signature to a preset position of the initial access token, and obtaining the target access token includes:

[0053] Enter plain text Public key pk and integer st;

[0054] calculate: c←Ar+Dm modqR, r←F(st); SampleD() represents the sampling algorithm; st←st+1;

[0055] Output digital signature: sig = (τ, v);

[0056] The generated digital signature is attached to a preset position of the initial access token to obtain a target access token.

[0057] Preferably, the target access token is sent to the client, so that the client verifies the digital signature in the target access token based on the public key using the Verify(pk, m, sig)→0 / 1 of the lattice signature algorithm, and if the verification matches, the target access token is considered safe, and the target access token is attached to an authorization request to request access to a resource to be accessed owned by a user, including:

[0058] The client receives the target access token and the public key;

[0059] Input public key pk, plaintext Digital signature sig and public parameter pp;

[0060] Calculate:

[0061]

[0062] Output b;

[0063] If b = 0, the verification fails; if b = 1, the verification matches, the target access token is considered safe, and the target access token is attached to an authorization request to request access to a resource to be accessed owned by a user.

[0064] The above technical solutions of the present application have the following beneficial effects compared with the prior art:

[0065] The resource access method based on OAuth2.0 token security enhancement according to the present application obtains a key pair including a public key and a private key based on a preset encryption algorithm; the initial access token is digitally signed using the private key, and the generated digital signature is attached to a preset position of the initial access token to obtain a target access token; the server sends the target access token to the client, and the client verifies the digital signature in the target access token using the public key of the server and the preset encryption algorithm after receiving it, to ensure that the target access token is authentic, thereby ensuring the secure transmission of the authorization code and the token and the access security of the resource to be accessed;

[0066] When the preset encryption algorithm of the present application is the elliptic curve public key cryptography algorithm SM2, the initial access token is signed using the SM2 digital signature algorithm, the signature is generated and verified to ensure that the token is not tampered with or forged during transmission, thereby improving the security during transmission, effectively preventing man-in-the-middle attacks and replay attacks, ensuring autonomous controllability, and improving the security of resource access;

[0067] When the preset encryption algorithm of the application is a lattice signature algorithm, the initial access token is signed using the lattice signature algorithm, the lattice signature algorithm is based on lattice theory, has higher anti-quantum computing capability, provides additional security in a quantum computing environment, ensures the security of the system under future quantum computing threats, and thus improves the security of resource access. BRIEF DESCRIPTION OF DRAWINGS

[0068] In order to make the content of the application more easily understood, the application will be further described in detail below according to specific embodiments of the application and in conjunction with the drawings, in which

[0069] Figure 1 is a step flow chart of the resource access method based on the OAuth2.0 token security enhancement provided by the application;

[0070] Figure 2 is a flow chart of the OAuth2.0 authorization code mode based on the SM2 digital signature algorithm lattice signature algorithm provided by the application;

[0071] Figure 3 is a timing diagram of a conventional OAuth2.0 authorization code interception attack;

[0072] Figure 4 is a timing diagram of the OAuth2.0 authorization code secure transmission mechanism based on the SM2 digital signature in the application;

[0073] Figure 5 is a token security enhancement mechanism module relationship connection diagram for preventing authorization code interception attacks in the open authorization protocol provided by the application. DETAILED DESCRIPTION

[0074] The application will be further described below in conjunction with the drawings and specific embodiments, so that those skilled in the art can better understand the application and implement it, but the embodiments are not limiting the application.

[0075] Referring to Figure 1 the step flow chart of the resource access method based on the OAuth2.0 token security enhancement provided by the application, the specific steps include:

[0076] When receiving an authorization request initiated by a client, an authorization code is obtained and returned to the client; the client-initiated authorization request is triggered when a user applies for access to the client;

[0077] Receiving a token application request based on the authorization code proposed by the client, if the authorization code is correct, generating an initial access token;

[0078] According to the token security vulnerability, a corresponding preset encryption algorithm is selected; based on the preset encryption algorithm, a key pair containing a public key and a private key is obtained;

[0079] The initial access token is digitally signed by using the private key, and the generated digital signature is attached to a preset position of the initial access token to obtain a target access token;

[0080] The target access token is sent to the client, so that the client verifies the digital signature in the target access token based on the public key and by using the preset encryption algorithm, and if the verification is successful, it is considered that the target access token is safe, and the target access token is attached to the authorization request to request access to the resource owned by the user.

[0081] The existing OAuth2.0 protocol is complex to implement, has no authentication measures, lacks encryption mechanisms, has a high risk of token leakage, is difficult to manage refresh tokens, faces risks in cross-domain requests, has trust problems with clients, and affects user experience. In order to make up for these shortcomings, some means can be taken to strengthen the security mechanism, especially two important aspects need to be considered: self-controlling and anti-quantum attack, so two advanced signature technologies are introduced: SM2 digital signature algorithm and lattice signature algorithm. In the aspect of self-controlling, the SM2 digital signature algorithm simplifies the token signing and verification process, solves the problem of implementation complexity, and fills the gap of no authentication measures and lack of encryption mechanisms by providing powerful digital signature function, thereby reducing the risk of token leakage. In the aspect of anti-quantum attack, the lattice signature algorithm simplifies the management of refresh tokens through efficient signature and verification mechanism, ensures the secure transmission of tokens in cross-domain requests, enhances the trust of clients to tokens, and provides anti-quantum computing capability to ensure the security of the system in the future quantum computing environment. The lattice algorithm provides efficient anti-quantum attack based on complex mathematical solving problems, is suitable for various cryptographic applications, and resists future quantum threats. Therefore, the present application considers the current OAuth2.0 token security vulnerabilities and the needs of self-controlling and anti-quantum computing theory, and introduces two mechanisms:

[0082] The first mechanism is a token vulnerability security enhancement mechanism based on the SM2 digital signature algorithm. The SM2 digital signature algorithm is introduced in the OAuth2.0 protocol to realize digital signature through encryption mechanism, optimize the implementation process, and reduce the risk of token leakage. When the client requests a token from the authorization server through an authorization code, the authorization server signs the token using a private key and the SM2 digital signature algorithm to ensure self-controlling and prevent token theft or forgery. The authorization server sends the signature result to the client together with the token, and the client verifies the signature using the public key of the authorization server and the SM2 digital signature algorithm to ensure that the token has not been tampered with or forged during transmission, thereby improving the security during transmission, effectively preventing man-in-the-middle attacks and replay attacks, and ensuring self-controlling.

[0083] The second mechanism is a token vulnerability security enhancement mechanism based on lattice signature algorithm; the lattice signature algorithm is introduced in the OAuth2.0 protocol, and the token security and cross-domain request protection are improved by enhancing the authentication and encryption technology, and the client trust is enhanced. When the client requests the token, the authorization server uses the private key and the lattice signature algorithm to sign the token, has higher anti-quantum computing capability, resists quantum attack, prevents the token from being stolen or forged, and improves the overall security. The authorization server sends the signature result and the token to the client, and the client verifies the signature by using the public key of the authorization server and the lattice algorithm after receiving, ensures that the token is real, embodies the anti-quantum attack advantage of the lattice signature algorithm, provides additional security protection in the quantum computing environment, and ensures the security of the system under the threat of quantum computing in the future.

[0084] Therefore, the application selects the corresponding preset encryption algorithm according to the token security vulnerability, including:

[0085] Embodiment 1: when the token security vulnerability includes man-in-the-middle attack and replay attack, the elliptic curve public key cryptography algorithm SM2 is selected as the preset encryption algorithm;

[0086] Embodiment 2: when the token security vulnerability includes quantum computing threat, the lattice signature algorithm is selected as the preset encryption algorithm.

[0087] The resource access method for token security enhancement based on OAuth2.0 provided by the application obtains a key pair including a public key and a private key based on a preset encryption algorithm; the initial access token is digitally signed by using the private key, the generated digital signature is attached to a preset position of the initial access token, and a target access token is obtained; the server sends the target access token to the client, and the client verifies the digital signature in the target access token by using the public key of the server and the preset encryption algorithm after receiving, ensures that the target access token is real, and ensures the secure transmission of the authorization code and the token and the access security of the to-be-accessed resource.

[0088] Embodiment 1:

[0089] The elliptic curve public key cryptography algorithm SM2 is mainly used for public key encryption and digital signature. It is based on elliptic curve cryptography (ECC) and has high security and computational efficiency, and is widely used in various secure communication and identity verification scenarios. In the OAuth2.0 protocol, the SM2 digital signature algorithm is introduced, which can protect the transmission security of tokens through SM2 digital signature technology, prevent them from being eavesdropped or tampered with during transmission. Specifically, using SM2 digital signature to sign the token can achieve autonomous control and prevent token theft or forgery. The authorization server signs the generated token using the SM2 private key, and the client verifies it using the SM2 public key after receiving the token to ensure that the token has not been tampered with during transmission. In this way, the SM2 digital signature algorithm can effectively improve the security of tokens in the OAuth2.0 protocol, preventing authorization code interception attacks and other potential threats. Digital signature is a digital signature generated by a signer for a message (data), which is verified by a verifier for the legality of the signature. Each signer has a pair of public and private keys, the signer signs with the private key, and the verifier verifies with the public key of the signer.

[0090] Specifically, when the token security vulnerability includes man-in-the-middle attacks and replay attacks, the elliptic curve public key cryptography algorithm SM2 is selected as the preset encryption algorithm, and at this time:

[0091] S101: Based on the elliptic curve public key cryptography algorithm SM2, a key pair including a public key and a private key is generated using SM2.KeyGen(λ), including:

[0092] S101-1: The preset elliptic curve E is defined on the finite field F p , and for a given security parameter λ, a, b, G = (x G , y G ) are selected, a and b are equation parameters of the elliptic curve, G is a q-order base point on the elliptic curve E, and (x G , y G ) are the coordinates of the base point;

[0093] S101-2: Using the SM3 hash function and the random number generator, the server is the signer, and the private key is randomly generated, denoted as: sk A = x, x ∈ [1, q-1], q represents the order of the elliptic curve E;

[0094] S101-3: Based on the private key, the preset elliptic curve and the base point are used to calculate the corresponding public key, denoted as: pk A = xG = (x A , y A ).

[0095] S102: based on SM2.Sign(m), using a private key, digitally signing the initial access token, and attaching the generated digital signature to the initial access token at a preset position, obtaining a target access token, comprising:

[0096] S41: based on the resource to be accessed m, obtaining a signer identification ID with a length of entlen A bits A , and converting it into two bytes to obtain a two-byte identification ENTL A ;

[0097] S42: the server calculates the identity identification, denoted as: Z A = H 256 (ENTL A ||ID A ||a||b||x G ||y G ||x A ||y A );

[0098] S43: select a random number k, multiply it with the base point, and obtain the private key kG = (x1, y1);

[0099] S44: using the SM3 hash function, calculate the hash value of the identity identification Z A , the resource to be accessed m, and the x-coordinate x1 of the private key, denoted as: r = (e + x1) mod q, e = H v (Z A ||m);

[0100] S45: if the hash value r satisfies r = 0 or r = q-k, return to step S43 to reselect the random number k, until the hash value r satisfies r ≠ 0 and r ≠ q-k, then calculate the signature value, denoted as: s = (1+x) -1 (k-rx) mod q;

[0101] S46: if the signature value s = 0, return to step S43 to reselect the random number k, until the signature value s ≠ 0,

[0102] S47: attach the signature value to the header position of the initial access token to obtain the target access token.

[0103] S103: send the target access token to the client, so that the client uses the elliptic curve public key cryptography algorithm SM2 based on the public key to verify the digital signature in the target access token, and obtains a Boolean value, if the Boolean value is True, it is considered that the target access token is safe, and the target access token is attached to the authorization request to request access to the resource to be accessed by the user, comprising:

[0104] S103-1: The client receives a target access token and a public key;

[0105] S103-2: Verify whether the digital signature in the target access token is correct by using SM2.Verify(m',σ'), including:

[0106] For the to-be-verified digital signature of the to-be-accessed resource m', the signature content σ'=(r',s'), if r',s'=0, the verification fails;

[0107] If r',s'≠0, calculate e'=H v (Z A ||m'), t=(r'+s')mod q, if t=0, the verification fails;

[0108] If t≠0, calculate (x1',x2')=s'G+tX, R=(e'+x1')mod q, if R=r', the verification passes, output 1, otherwise the verification fails, output 0;

[0109] S103-3: If the verification succeeds, it is considered that the target access token is secure, and the target access token is attached to the authorization request to request access to the to-be-accessed resource owned by the user;

[0110] Wherein, m' represents the to-be-verified digital signature of the to-be-accessed resource, σ' represents the signature content, including two parts r' and s', represented as σ'=(r',s').

[0111] Specifically, the formulaic description of the SM2 digital signature algorithm includes:

[0112] 1. Initialize SM2.Setup(λ): E is an elliptic curve defined on a finite field , for a given security parameter λ, select a, b, q, n, G=(x G , y G ), SM3 hash function H 256 : Hash function h: and random number generator, wherein a, b, q, n are elliptic curve equation parameters, G is a q-order base point (generator) on E, (x G , y G ) is the coordinate of the base point, let be the cyclic group generated by G. Conversion function f: defined as f(Q)=x Q mod n, wherein x Q is an integer representation of the x-coordinate of the elliptic curve point .

[0113] The signature algorithm SM2.Sign(m): the signer first pre-processes the message, and let ID A be the length of the signer, entlen A bits, ENTL A be two bytes converted from entlen A , calculate Z A = H 256 (ENTL A || ID A || a || b || x G || y G || x A || y A ), select a random number k∈[1, q-1], calculate x1=f(kG); calculate e=h(Z A || m), r=(e+x1)mod q, if r=0 or r=q-k, return to reselect the random number. Finally, calculate s=(1+x) -1 (k-rx)mod q, if s=0, return to reselect.

[0114] The public key verification algorithm SM2.Verify(m', σ'): for the to-be-verified m', σ'=(r', s'), the verification process is as follows: if r', s'=0, the verification fails; otherwise, calculate e'=h(Z A || m'), t=(r'+s')mod q, if t=0, the verification fails, otherwise calculate x1'=f(s'G+tX), R=(e'+x1')mod q, if R=r', the verification passes, output 1, otherwise the verification fails, output 0.

[0115] Based on the above embodiment, in the embodiment of the application, the elliptic curve public key cryptography algorithm SM2 is used as the encryption algorithm, and the SM2 digital signature algorithm is introduced in the OAuth2.0 protocol to realize autonomous controllability. When the client requests a token from the authorization server through an authorization code, the authorization server signs the token using a private key and the SM2 digital signature algorithm to ensure autonomous controllability and prevent the token from being stolen or forged; the authorization server sends the signature result to the client together with the token, and the client verifies the signature using the public key of the authorization server and the SM2 digital signature algorithm to prevent the server from being impersonated, realize autonomous controllability, including: in the system initialization phase, the authorization server generates a pair of SM2 key pairs, including a private key and a public key. The private key is used for signing, and the public key is used for verifying the signature. When the authorization server generates a token, the private key is used to sign the token content. The signature algorithm generates a unique signature value according to the mathematical properties of the elliptic curve, and the signature value is sent to the client together with the token content. The authorization server sends the signed token and the signature result to the client. After receiving the signed token, the client verifies the signature using the public key of the authorization server. After receiving the signed token, the client verifies the signature using the public key of the authorization server. The verification algorithm calculates and compares the signature value to ensure that the token has not been tampered with during transmission. After successful verification, the client can ensure the authenticity and integrity of the token.

[0116] Based on the above embodiment, referring to Figure 2 , which is a flowchart of the OAuth2.0 authorization code mode based on the SM2 digital signature algorithm, specifically including:

[0117] (A) User accesses the client: the user accesses the client Client through a browser or other user agent.

[0118] (B) Client generates an authorization request: the client generates an authorization request containing client ID, redirect URI, requested permission range and other information, and sends the request to the authorization server (Authorization Server).

[0119] (C) User selects whether to grant the client authorization: the authorization server directs the user to an authorization page, and the user selects whether to grant the client authorization on the page.

[0120] (D) Authorization server verifies the request and sends the authorization code: after receiving the authorization request, the authorization server verifies its legality and integrity. If the user agrees to authorize, the authorization server generates an authorization code and redirects the authorization code to the callback address (redirect URI) of the client through the user agent (browser).

[0121] (E) Client carries authorization code to request access_token: After receiving the authorization code, the client sends a request to the / token endpoint of the authorization server, carrying the authorization code and other necessary authentication information.

[0122] (F) Authorization server generates and signs access_token: The authorization server verifies the validity of the authorization code. After verification, the authorization server generates an access_token. The access_token is signed using the SM2 private key to generate a signature result S_SM2. The authorization server returns the signed access_token and signature result S_SM2 to the client.

[0123] (G) Client verifies signature and uses access_token: After receiving the signed access_token and signature result S_SM2, the client verifies the validity of the signature using the SM2 public key of the authorization server. After successful verification, the client uses the access_token to access the protected resources on the resource server.

[0124] (H) Resource server verifies access_token: The resource server receives the client request and forwards the request to the CA (Certificate Authority). The CA verifies the validity of the access_token. After verification, the resource server returns the protected resources to the client.

[0125] Referring to Figure 3 , it is a traditional OAuth2.0 authorization code interception attack timing diagram, and its steps are as follows:

[0126] ① User accesses client: The user accesses the client (Client) through the browser or other user agent;

[0127] ② Client generates authorization request: The client generates an authorization request containing client ID, redirect URI, requested permission range, etc. information, and sends the request to the authorization server (Authorization Server);

[0128] ③ Attacker impersonates authorization server: The attacker impersonates the authorization server by some means (such as DNS hijacking, malicious Wi-Fi hotspot, etc.) and intercepts or forges the response of the authorization server;

[0129] ④ User selects whether to grant authorization to client: The user selects whether to grant authorization to the client on the authorization page;

[0130] The authorization server sends a real authorization code: after obtaining the message of the user's consent authorization, the authorization server sends an authorization code to the client, but the response of the imitated authorization server has been intercepted or the response of the fake authorization server has been imitated, so the authorization code is not sent to the client, but is intercepted by the imitated authorization server;

[0131] The attacker sends a false authorization code: if the user agrees to authorize, the attacker generates a false authorization code, and redirects the false authorization code to the callback address (redirection URI) of the client through the user agent (browser);

[0132] The client carries a false authorization code to request access_token: after the client receives the false authorization code, the client sends a request to the / token endpoint of the imitated authorization server (actually a server controlled by the attacker) carrying the false authorization code and other necessary authentication information.

[0133] The attacker intercepts the real authorization code request: the attacker intercepts the real authorization code request sent by the client;

[0134] The attacker uses the real authorization code to request access_token: the attacker uses the intercepted real authorization code to request access_token from the real authorization server;

[0135] The authorization server generates access_token: the authorization server verifies the validity of the real authorization code and generates access_token.

[0136] The attacker obtains a legal access_token: the attacker uses the legal access_token to access the protected resources on the resource server;

[0137] The attacker obtains the protected resources: the resource server verifies the access_token and returns the requested protected resources;

[0138] Referring to Figure 4 The timing diagram of the OAuth2.0 authorization code secure transmission mechanism based on SM2 digital signature is shown. The steps are as follows:

[0139] The user accesses the client: the user accesses the client (Client) through the browser or other user agent;

[0140] The client generates an authorization request: the client generates an authorization request containing the client ID, redirection URI, requested permission range and other information, and sends the request to the authorization server;

[0141] The user selects whether to give the client authorization: the authorization server guides the user to an authorization page, and the user selects whether to give the client authorization on the page;

[0142] If the user agrees to authorize, the authorization server generates an authorization code;

[0143] The authorization server verifies the request and sends the authorization code, and the authorization server receives the authorization request, verifies its legality and integrity, and redirects the authorization code to the callback address (redirect URI) of the client through the user agent (browser);

[0144] The client carries the authorization code to request access_token: after the client receives the authorization code, it sends a request to the / token endpoint of the authorization server, carrying the authorization code and other necessary authentication information.

[0145] The authorization server generates and signs access_token: the authorization server verifies the validity of the authorization code. After verification, the authorization server generates access_token. The access_token is signed using the lattice signature algorithm to generate a signature result S_G.

[0146] The authorization server sends the signed access_token and signature result S_G and public key to the client;

[0147] The client verifies the signature, and after the client receives the signed access_token and signature result S_G, it verifies the validity of the signature using the lattice signature public key of the authorization server;

[0148] After verification, the client uses access_token to access the protected resources on the resource server;

[0149] The resource server verifies access_token: the resource server receives the client request and forwards the request to the CA (Certificate Authority). The CA verifies the validity of access_token. After verification, the resource server returns the protected resources to the client.

[0150] The embodiment of the application uses JWT to sign and verify in OAuth2.0, the application of SM2 signature algorithm in JWT and access token, and the authentication process between the client and the resource server.

[0151] In the traditional OAuth2.0, the authorization server uses JWT (JSON Web Tokens) for signature, which can securely transmit user information and access permissions between the client and the resource server, and the process is as follows:

[0152] 1) Generate JWT: After verifying the identity and permissions of the client (such as a user agent or third-party application), the authorization server generates a JWT.

[0153] 2) Sign JWT: The authorization server signs the header and payload of the JWT using a private key.

[0154] 3) Send JWT: The signed JWT is sent to the client, which can carry this JWT in subsequent requests to access protected resources.

[0155] 4) Verify JWT: When the resource server receives a request, it extracts the JWT from the request and then uses the same public key as the authorization server (or a symmetric key, depending on the signature algorithm) to verify the signature of the JWT. If the signature is valid and the JWT has not expired, the resource server will allow access to the requested resource.

[0156] However, JWTs face risks such as key leakage, vulnerability to man-in-the-middle attacks, threats of replay attacks, and leakage of payload information.

[0157] Specifically, the JWT signature verification process of SM2 digital signature includes:

[0158] 1) Set Payload, including iss (Issuer): the issuer of the JWT, exp (Expiration Time): the expiration time of the JWT, which is a timestamp, scope (scope): an optional field that defines the permission range of the JWT, and other custom fields such as value (if referring to a certain field in the payload, define it here), which are encoded into a JSON object and Base64 encoded.

[0159] 2) Set Header, specify the signature algorithm as SM2 (although the JWT standard itself may not directly support SM2, it can be implemented through custom or extended libraries), Header usually contains typ (Token type, usually JWT) and alg (signature algorithm used), encode Header into a JSON object and Base64 encode.

[0160] 3) Signature, concatenate the Base64 encoded Header and Payload into a string using a period (.), and sign the string using a private key and a specified signature algorithm (SM2), and Base64 encode the signature result.

[0161] 4) Assemble JWT, concatenate the Base64 encoded Header, Payload, and signature result into a complete JWT string using a period.

[0162] If the signature is not consistent, an error will be thrown, including:

[0163] 1) Parse the JWT, split the JWT string into Header, Payload and signature three parts according to the dot, and decode the Header and Payload parts to obtain the original JSON pair 2) Verify the signature, use the public key and the same signature algorithm (SM2) to verify the splicing string of Header and Payload, and compare whether the verification result is consistent with the signature part in the JWT.

[0164] 3) Check the fields in the Payload, verify whether the exp (expiration time) and other fields meet the requirements, and if the JWT contains scope or other custom fields, perform corresponding verification according to business requirements.

[0165] The authorization code is used in the authentication process between the client (such as a web application, mobile application or desktop application) and the resource server (server providing protected resources) to securely obtain access tokens (access tokens), and then use these access tokens to access protected resources. The client and resource server authentication process specifically includes:

[0166] 1) After receiving the authorization code, the client will use the authorization code, the client's secret key (client_secret, which is required for some types of clients), the client ID and the redirect URI to send a request to the token endpoint of the authorization server to exchange the access token.

[0167] 2) The authorization server uses the SM2 algorithm to sign the access token (access token), and the signature result is sent to the client along with the token. After obtaining the access token, the client uses the token to request protected resources from the resource server. The access token is included in the header of the HTTP request, usually using the Authorization header and specifying the Bearer mode.

[0168] 3) After receiving the request, the resource server will verify the validity of the access token. If the token is valid, the resource server will return the requested resource; if the token is invalid or has expired, the resource server will return an appropriate error response.

[0169] Based on the above embodiment, the security of the token vulnerability security enhancement method based on the SM2 digital signature algorithm when the elliptic curve public key cryptography algorithm SM2 is selected as the preset encryption algorithm is specifically proved as follows:

[0170] In the OAuth2.0 authorization code mode, the security of the token is crucial, and security problems such as authorization code interception attacks can seriously threaten the security of the system, in order to enhance the security of the token, the application proposes a token vulnerability security enhancement mechanism based on SM2 digital signature algorithm.

[0171] The token generation and verification process based on the SM2 digital signature algorithm includes the following steps:

[0172] 1) Key generation: generate a public-private key pair pk, sk.

[0173] 2) Signature generation: use the private key sk to sign the token m to generate the signature (r, s).

[0174] 3) Signature verification: use the public key pk to verify the signature (r, s).

[0175] Security assumptions and threat models: Assuming that the attacker can intercept and forge the authorization code, the security goal of the system is to prevent forgery, interception and replay attacks, and the attacker's capabilities include: intercepting legitimate tokens and signatures and forging legitimate signatures.

[0176] Specifically, the security proof includes:

[0177]

[0178] params←Setup(1 κ );;(PK,SK)←Keygen(params);

[0179]

[0180]

[0181] Otherwise,return 0.

[0182] Signing oracle Sign(params,SK,m)

[0183] σ←Sign(params,SK,m);

[0184]

[0185] Returnσ.

[0186] Definition 1: (EUF-CMA) If for any probabilistic polynomial time (PPT) adversary F, there exists a negligible function v(·) such that Definition in the security proof is such that A signature scheme is said to be existentially unforgeable under adaptive chosen message attacks (EUF-CMA).

[0187] Lemma 1: If h is a uniform and collision-resistant hash function, and the transformation function f is almost invertible, then the SM2 signature is existentially unforgeable against tokens m in the generic group model.

[0188] In the generic group model, it is noted that the attacker does not have direct access to the group itself, but only obtains "handles" representing group elements. Specifically, the attacker must interact with an oracle to perform group operations (including scalar multiplication and addition) and obtain handles for new elements. In particular, it is assumed that the attacker can only use handles previously received from its environment. In the present invention, in addition to obtaining group element handles directly from group operation queries, the attacker can also obtain handles from the signatures obtained from public key and signature oracle queries. In fact, the attacker can use the handles in the public key and signatures as "bases" to further perform group operations. More formally, let (G, Y) be a group element handle in the public key, and let be a group element handle created in a signature query, where q s is the number of signature queries issued by the attacker. According to the assumption, all group elements that the attacker wants to compute have the form where is a known integer selected by the attacker. Thus, all group operation queries can be unified by a coefficient vector For example, multiplying the primitive element G by an integer z can be represented as a group operation query (z, 0,..., 0).

[0189] Proof: In the following, for any polynomial-time probabilistic algorithm forger F, it will be shown that there exists a challenger C that can simulate the attack environment for F such that the advantage of F becomes negligible. To respond to group operation queries from F, the challenger C will maintain a table L to record information generated in the group operation queries. Specifically, C first generates the handle of the primitive element by selecting an element and adds (1, G, -, -) to the table L, where is a set that supports efficient sampling and represents the underlying group. Then, C selects an integer as the handle of the result of multiplying G by d, and adds (d, Y, -, -) to the table L. Let q s be the number of signature queries made by F, q c be the current number of signature queries in the interaction between C and F, and let represents a group element handle generated in a signature query. C answers F's group operation queries and signature queries in the following way.

[0190] For a group operation query with input (that is, F wants to compute C performs the following operations: let j be the largest index such that z j ≠ 0. If j > q c + 2, return and exit. Otherwise, for all i e {1,...,j}, retrieve k i from the entry (k i ,V i ,-,-) in table L and compute z' = z1+z2d+z3k1+...+z j k j mod n. If there exists an entry (z', V', -, -) in table L, C directly returns V' to F.

[0191] Otherwise, it distinguishes the following two cases:

[0192] Case 1: if z2= 0, select and add to table L. Finally, return V' to F.

[0193] Case 2: if z2≠ 0, randomly select

[0194] and compute:

[0195] until Then add to table L and return V' to F.

[0196] For a signature query on a message m, C selects a set of values by itself and initiates a group operation query (k, 0,..., 0) to obtain a handle V. Next, C computes x = f(V), r = h(Z || m) + x mod n and s = (k - rd) / (l + d) mod n, where Z is other information determined according to the SM2 signature algorithm. Finally, C returns (r, s) as the signature on m to F.

[0197] After the above two types of polynomial-time queries, the adversary F will output a valid fake signature (r * ,s * ) on the message. Next, it is proved that the probability that the fake signature is valid is negligible under the assumption that h is uniformly distributed and collision-resistant.

[0198] It is only required to show that the probability that (r * ,s * ) is a valid signature for m * is negligible. Note that the secret key d is completely hidden from the adversary F. This is because, in the generic group model, d is chosen independently of the group element handle Y in the public key, and in the signature query (r,s), d is completely hidden from the signature (because of the random choices of k and V). Let k * = s * +(s * +r * )d, then (r * ,s * ) is a valid signature for m * if and only if there exists an entry (k * ,V * ,-,-) in the list L that satisfies r * -h(Z‖m * ) = f(V * ). First, claim that holds with overwhelming probability. Otherwise, the adversary can compute d from (r * ,s * ) with certainty, which contradicts the fact that d is completely hidden from the adversary F, using the facts that s * ≠ 0 and s * +r * ≠ 0. In other words, V * can only be created in response to a group operation query or a signature query.

[0199] Distinguish between the following two cases:

[0200] Case 1: If then let V * = V i for some i, and let (r i ,s i ) be the signature on some message m i and auxiliary information Z i in the i-th signature query. In other words, it can be concluded that s * +(s * +r * )d = s i +(s i +r i )d. Since the secret key d is completely hidden from the adversary F, this case can only occur when s * +r * = s i +r i and s * = s iIt can only occur with a non-negligible probability when both are true. In this case, (r * ,s * ) is m * A valid signature is valid if and only if the equation h(Z i ‖m i )=r i -f(V i )=r * -f(V * )=h(Z‖m * ) is established. Since m * ≠m i , which means that F must find a collision for the hash function h (Z i ‖m i ,Z‖m * ). Under the assumption that h is collision-resistant, this situation can only occur with negligible probability.

[0201] Case 2: Otherwise, V * is through with input In this case, we can conclude that Again, since the secret key d is completely hidden from the adversary F, this situation only occurs if and Only when both of them are true at the same time can it happen with a non-negligible probability. Through simple calculation, we can get Furthermore, according to C's strategy (in case 2), there exists a pair (Z', m') chosen by C such that In other words, (r * ,s * ) is a valid signature if and only if h(Z‖m * )=r * -f(V * )=h(Z′‖m′). However, assuming that h is collision-resistant, the adversary F outputs a pair of (Z‖m * ) so that h(Z‖m * The probability that ) = h(Z′∥m′) is negligible.

[0202] In summary, it has been shown that under the assumption that h is uniformly distributed and collision-resistant, (r * ,s * ) becomes a valid signature on m* with a negligible probability, which is proved.

[0203] Example 2:

[0204] Lattice signature is a digital signature mechanism based on lattice cryptography, which has strong resistance to quantum attacks. By introducing the lattice signature mechanism, the security of the OAuth2.0 protocol can be further improved, especially in the face of future quantum computing threats. The lattice signature mechanism is used to digitally sign the token, ensuring its integrity and non-repudiation during transmission. In specific operations, the authorization server uses the lattice signature algorithm to sign the generated token, and the client verifies the token using the lattice signature public key after receiving the token to ensure that the token has not been tampered with during transmission. In this way, the lattice signature algorithm can effectively improve the authenticity and security of the token in the OAuth2.0 protocol.

[0205] Based on the above embodiments, in the embodiments of the present application, the lattice signature algorithm is used as the encryption algorithm, and the lattice signature algorithm is introduced into the OAuth2.0 protocol to resist quantum attacks. When the client requests a token, the authorization server uses a private key and a lattice signature algorithm to sign the token to resist quantum attacks, prevent token theft or forgery, and improve overall security; the authorization server sends the signed result and the token to the client, and the client verifies the signature using the public key of the authorization server and the lattice algorithm to ensure the authenticity of the token source and demonstrate the advantages of the lattice signature algorithm in resisting quantum attacks.

[0206] Specifically, when the token security vulnerability includes quantum computing threats, the lattice signature algorithm is used as the preset encryption algorithm, including:

[0207] S201: Based on the lattice signature algorithm, generate public parameters using Setup(λ)→pp; based on the public parameters, generate a key pair including a public key and a private key using KeyGen(pp)→(pk,sk), including:

[0208] S201-1: Pre-set positive integers d, ω, κ, k≤n, randomly select a prime number q, satisfying q=2k+1mod4k and Calculate: m2←d κ , m←m1+m2; randomly select a positive integer m3, let Calculate Select a positive integer t, calculate:

[0209] Get public parameters: pp=(D;g;λ,n,d,m1,m2,m3,q,ω,κ,σ,σ2,σ1); where τ is an element in the set S bin , represents random sampling in the integer set , and r represents the set Any one element, n represents a natural number, D represents a matrix randomly and uniformly selected from a set

[0210] S201-2: Based on the public parameter, select from The public key and the private key are obtained by using KeyGen (pp) -> (pk, sk), which are represented as: pk = (A, B, u), sk = R; wherein A represents a matrix randomly and uniformly selected from a set R represents a matrix randomly and uniformly selected from a set

[0211] S202: Based on Sign (m, pk) -> sig, the initial access token is digitally signed by using the private key, and the generated digital signature is attached to the preset position of the initial access token to obtain the target access token, including:

[0212] S202-1: Input plaintext Public key pk and integer st;

[0213] S202-2: Calculate: c <- Ar + Dm mod qR, r <- F (st) ; SampleD () represents a sampling algorithm; st <- st + 1;

[0214] S202-3: Output digital signature: sig = (tau, v) ; The generated digital signature is attached to the preset position of the initial access token to obtain the target access token.

[0215] S203: The target access token is sent to the client, so that the client verifies the digital signature in the target access token based on the public key by using the Verify (pk, m, sig) -> 0 / 1 of the lattice signature algorithm, if the verification matches, it is considered that the target access token is safe, and the target access token is attached to the authorization request to request access to the resource to be accessed owned by the user, including:

[0216] S203-1: The client receives the target access token and the public key;

[0217] S203-2: Input public key pk, plaintext Digital signature sig and public parameter pp;

[0218] S203-3: Calculate:

[0219]

[0220] ​​S203-4: output b; if b=0, the verification fails; if b=1, the verification matches, it is considered that the target access token is safe, and the target access token is attached to the authorization request to access the resource to be accessed owned by the user.

[0221] The present application proposes a token vulnerability security enhancement mechanism based on lattice signature algorithm to address the token security vulnerability of OAuth2.0 and the need for quantum attack resistance, including: the authorization server generates a pair of lattice signature key pairs in the initialization phase, including a private key and a public key. The private key is used for signing, and the public key is used for verifying the signature. After generating the token, the authorization server signs the token using the lattice signature algorithm. Unlike traditional signature algorithms, the lattice signature algorithm is based on the mathematical properties of lattice theory, and the generated signature has higher security, especially when facing quantum computing attacks. The authorization server sends the token signed using the lattice signature algorithm and the signature result to the client. After receiving the signed token, the client will use the lattice signature public key of the authorization server for verification. After receiving the signed token, the client uses the lattice signature public key of the authorization server to verify the signature. The verification algorithm ensures the authenticity and integrity of the signature through complex mathematical calculations. Through verification, the client can confirm that the token has not been tampered with or forged during transmission.

[0222] Specifically, the formulaic description of the lattice signature algorithm includes:

[0223] In cryptography, lattices are a multi-dimensional geometric structure that plays a central role in designing quantum-resistant encryption algorithms. The following gives its symbolic description and signature scheme:

[0224] Definition of lattice: a full-rank lattice of rank n is a discrete additive subgroup of The dual lattice of is defined as the set of all vectors in the generated space of whose inner product with all vectors y in is an integer, i.e. for The q-ary lattice family used by this scheme is defined as:

[0225] The following is a symbolic description: when a When a=1, b≥1, use [b] to represent [1,b]. Vectors are represented by bold lowercase letters, such as a, while matrices are represented by bold uppercase letters, such as A. The transpose operator is represented by the superscript T. The n x n identity matrix is represented by I n . For any , its Euclidean norm (l2 norm) is defined as The infinity norm l∞ ||a|| ∞ =(max i∈[m] |a i |), for a finite set S, |S| is defined as its cardinality (i.e., the number of elements in the set), and U(S) is the uniform probability distribution over the set S. The operation of drawing a sample x e S from a probability distribution P is denoted as x ← P. We use x ~ P to denote that the random variable x follows the distribution P, n is a power of two, and R is a cyclic unit ring of order 2n, i.e. For any modulus q ≥ 2, we have Let θ be the embedding factor of R, define S bin = θ -1 ({0,1} n ), S1 = θ -1 ({-1,0,1}).

[0226] The specific scheme is as follows:

[0227] Setup(λ)→pp: input the security parameter λ, output the public parameter pp. Select positive integers d, ω, κ, select k ≤ n, randomly select a prime number q, which satisfies q = 2k + 1 mod 4k and

[0228] Calculate: m2←d κ ,m←m1+m2.

[0229] Randomly select a positive integer m3, and let Calculate

[0230] Select a positive integer t > 0, and calculate:

[0231]

[0232] Output: pp = (D; g; λ, n, d, m1, m2, m3, q, ω, κ, σ, σ2, σ1).

[0233] KeyGen(pp)→(pk,sk): input the public parameter pp, output the public and private key pair (pk, sk).

[0234] Select:

[0235] Output: pk = (A, B, u), sk = R.

[0236] Sign(m, pk)→sig: input the plaintext public key pk, public parameter st, output the signature sig.

[0237] Calculate:

[0238] st←st+1;

[0239] Output signature sig = (τ, v).

[0240] Verify(pk, m, sig)→0 / 1: Input public key pk, plaintext signature sig, public parameters pp.

[0241] Compute:

[0242]

[0243] Output b = 0 / 1.

[0244] Using the public key obtained from the authorization server, the client performs signature verification on the hash value of the header and payload according to the algorithm Verify(pk, m, sig)→0 / 1. If the calculated signature matches the signature in the token, it can be considered that the token is valid and has not been tampered with.

[0245] Referring to Figure 2 , the embodiment proposes a flowchart of OAuth2.0 authorization code mode based on SM2 digital signature algorithm G signature algorithm, and the implementation process includes:

[0246] (A) User accesses the client: the user accesses the client (Client) through the browser or other user agent.

[0247] (B) Client generates an authorization request: the client generates an authorization request containing client ID, redirect URI, requested permission range, etc. Information, and sends the request to the authorization server (Authorization Server).

[0248] (C) User selects whether to grant the client authorization: the authorization server directs the user to an authorization page, and the user selects whether to grant the client authorization on this page.

[0249] (D) Authorization server verifies the request and sends the authorization code: after the authorization server receives the authorization request, it verifies its legality and integrity. If the user agrees to authorize, the authorization server generates an authorization code, and redirects the authorization code to the callback address (redirect URI) of the client through the user agent (browser).

[0250] (E) Client requests access_token with authorization code: after the client receives the authorization code, it sends a request to the / token endpoint of the authorization server, carrying the authorization code and other necessary authentication information.

[0251] (F) The authorization server generates and signs the access_token: The authorization server verifies the validity of the authorization code. After verification, the authorization server generates an access_token. The access_token is signed using the lattice signature algorithm to generate a signature result S_G, and the authorization server returns the signed access_token and the signature result S_G to the client.

[0252] (G) The client verifies the signature and uses the access_token: After receiving the signed access_token and the signature result S_G, the client verifies the validity of the signature using the lattice signature public key of the authorization server. After successful verification, the client uses the access_token to access the protected resources on the resource server.

[0253] (H) The resource server verifies the access_token: The resource server receives the client request and forwards the request to the CA (Certificate Authority). The CA verifies the validity of the access_token. After verification, the resource server returns the protected resources to the client.

[0254] Through the above steps and formula description, the present application realizes the improvement of the OAuth2.0 authorization code mode, ensures the authenticity and integrity of the token in the transmission process, and provides additional security in the future quantum computing environment.

[0255] Referring to Figure 5 The present application provides a token security enhancement mechanism module connection diagram for preventing authorization code interception attacks in the open authorization protocol, which mainly includes the following six modules:

[0256] 1) Apply token module, used to realize that the client applies for a token to the authentication server through the obtained authorization code;

[0257] 2) Authorization code verification module, used to verify whether the authorization code sent by the client is real by the authorization server;

[0258] 3) Token generation module, used to generate access tokens, including access permissions, user identity information, etc.;

[0259] 4) Digital signature module, used to sign the generated token and attach the generated digital signature to a part of the token (usually the header or body of the token), forming a complete access token;

[0260] 5) Signature verification module, used to verify the signature of the token by the client using the public key obtained from the authorization server, to ensure that the token has not been tampered with;

[0261] 6) a transmission module for implementing data transmission from the authorization code to the token in a network environment;

[0262] Specifically, the security of the token vulnerability security enhancement method based on the lattice signature algorithm is verified based on the OAuth2.0-based token security enhancement resource access method when the preset encryption algorithm is the lattice signature algorithm, including:

[0263] For a finite set S, define |S| as its cardinality (i.e., the number of elements in the set), and U(S) as a uniform probability distribution over the set S. The operation of drawing a sample x from a probability distribution P is denoted as x←P. We use x~P to represent that the random variable x follows the distribution P, n is a power of two, and R is a cyclic unit ring of order 2n, that is, For any modulus q≥2, there is Let θ be the embedding coefficient of R, and define S bin =θ -1 ({0,1} n ), S1=θ -1 ({-1,0,1}).

[0264] The security of the lattice signature algorithm is proved as follows:

[0265] Step 1: Worst-case to average-case reductions for module lattices proposes a hard problem that requires given a find a that satisfies Aw=0modqR and 0≤||w||2≤β, and the proof tools used all have a corresponding ring. This provides a theoretical security guarantee for lattice-based cryptographic systems, enabling the system to resist various potential attacks in practical applications.

[0266] Step 2: Ensure that the difference between different labels in R q is invertible. nvertible elements in partially splitting cyclotomic rings and applications to lattice-based zero-knowledge proofs indicates that when q=2k+1mod4k, if an element r in a ring is invertible in R ∞ . q is chosen to make the l norm of the difference between labels τ1-τ2 at most . Therefore, the difference between different labels is in and Ensure that As and The statistical distance does not exceed ε.

[0267] Step 3: When and When u = Av mod q, it is close to uniform distribution. A toolkit for ring-LWE cryptography proposes that if Then the public syndrome u in The distribution in space will be close to uniform. Although this conclusion is valid when the Gaussian distribution is defined according to the Minkowski embedding, in this scheme, since m1+m2≥d(log2(q) / log2(3)+κ)+f(λ) / log2(3), when , the above result holds true.

[0268] The evenly distributed public syndrome makes it difficult for attackers to infer the internal structure or parameters of the system by analyzing the intercepted authorization code, thereby increasing the difficulty of the attack.

[0269] Step 4: Estimate the upper bound of the spectral norm of a specific structured matrix. The elements in a given matrix are sampled according to the uniform distribution U([-1,1]), but the elements in a block are not independent of each other. For a structured matrix of size nm1×nm2, its spectral norm is actually equal to the maximum spectral norm of n complex embedding matrices of size m1×m2 (matrices in the real field are converted to the complex field). All elements of these complex embedding matrices are independent and identically distributed (iid) and obey the sub-Gaussian distribution, with On these embedding matrices, and using the union bound (on half of the complex embeddings), we get The upper bound of is C with extremely high probability, where C>0 is an absolute constant.

[0270] Lemma 1: If the adversary can create a Type I Forgery with an advantage of δ, then an algorithm can be constructed Can take advantage solve The calculation formula of β is:

[0271]

[0272] Lemma 2: If the adversary can create a Type II Forgery with an advantage of δ, then an algorithm can be constructed In satisfaction Under the conditions of solve Problem, where the formula for calculating β' is:

[0273]

[0274] Assumption: Assume there is an attacker A who can successfully forge an authorization code with a non-zero advantage, i.e., make Type I or Type II forgeries. Construct a reductio ad absurdum proof:

[0275] Reductio ad absurdum: Assume attacker A can successfully forge an authorization code. According to Lemma 1 and Lemma 2, an algorithm Use A's forgery ability to solve the hard problem on the lattice.

[0276] Contradiction: According to the hard problem on the lattice assumption, these problems are computationally difficult to solve, i.e., there is no efficient polynomial-time algorithm that can successfully solve these problems. Therefore, attacker A cannot successfully forge an authorization code.

[0277] Conclusion: Since the hard problem on the lattice is computationally difficult to solve, the attacker cannot successfully make Type I or Type II forgeries. Therefore, the token vulnerability security enhancement method based on lattice signature algorithm is secure and can effectively prevent authorization code interception attacks.

[0278] The present application uses SM2 digital signature algorithm and lattice signature algorithm, improves the security of data in the transmission process of the system, reduces the risk of authorized code and token being tampered or forged. By using SM2 digital signature algorithm, the integrity and authenticity of the token in the transmission process are ensured. The introduction of lattice signature algorithm improves the security of the token when facing quantum computing attacks, and reduces the shortcomings of traditional signature algorithms in high security demand environment. The lattice signature algorithm provides higher security than traditional algorithms through its complex mathematical structure and quantum computing resistance, so that the authorization code and token still have high security protection in the future quantum computing environment. The present application considers the common interception and forgery attacks in OAuth2.0 authorization code mode, uses SM2 digital signature algorithm and lattice signature algorithm, improves the overall security of the system, and reduces potential security vulnerabilities. By using these two advanced signature algorithms respectively, the present application not only improves the security of the token in the transmission process, but also verifies the security of the signature algorithm through mathematical proof, ensuring that the system can effectively defend against various attacks in practical applications.

[0279] The resource access method based on the OAuth2.0 token security enhancement provided by the application obtains a key pair containing a public key and a private key based on a preset encryption algorithm; the private key is used to digitally sign an initial access token, and a generated digital signature is attached to a preset position of the initial access token to obtain a target access token; the server sends the target access token to the client, and the client verifies the digital signature in the target access token by using the public key of the server and the preset encryption algorithm after receiving, to ensure that the target access token is authentic, so as to ensure the secure transmission of the authorization code and the token and the access security of the resource to be accessed; when the preset encryption algorithm of the application is an elliptic curve public key cryptography algorithm SM2, the initial access token is signed by using the SM2 digital signature algorithm, the signature is generated and verified, the token is ensured not to be tampered with or forged in the transmission process, and therefore the security in the transmission process is improved, the man-in-the-middle attack and the replay attack are effectively prevented, the self-controllability is ensured, and the security of resource access is improved; when the preset encryption algorithm of the application is a lattice signature algorithm, the initial access token is signed by using the lattice signature algorithm, the lattice signature algorithm is based on lattice theory and has higher anti-quantum computing capability, additional security guarantee is provided in a quantum computing environment, the security of the system under the threat of future quantum computing is ensured, and therefore the security of resource access is improved.

[0280] Those skilled in the art will understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage, etc.) containing computer-usable program code.

[0281] The present application is described with reference to flowcharts and / or block diagrams according to the methods, devices (systems), and computer program products of the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and the combination of flows and / or blocks in the flowcharts and / or block diagrams can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing apparatus produce a device that implements the functions specified in the flowcharts and / or block diagrams. Figure 1 The functions specified in one flow or multiple flows and / or blocks Figure 1 The functions specified in one flow or multiple flows and / or blocks

[0282] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0283] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that are executed on the computer or other programmable apparatus provide steps for implementing the Figure 1 function specified in the flow or flows and / or blocks Figure 1 of the block or blocks.

[0284] Obviously, the above-described embodiments are only examples and are not intended to limit the present application. Based on the above description, one of ordinary skill in the art can make other variations and changes without departing from the present application. It is not necessary to recite all the embodiments, and obvious changes or variations are not included in the present application.

Claims

1. A resource access method with enhanced token security based on OAuth2.0, characterized in that: Applicable to servers, including: When receiving an authorization request initiated by a client, obtaining and returning an authorization code to the client; the authorization request initiated by the client is triggered when the user applies to access the client; Receive the token application request from the client based on the authorization code. If the authorization code is verified to be correct, generate an initial access token; Select the corresponding preset encryption algorithm based on the token security vulnerability, including: When token security vulnerabilities include man-in-the-middle attacks and replay attacks, select the elliptic curve public key cryptography algorithm SM2 as the default encryption algorithm; When token security vulnerabilities include quantum computing threats, the lattice signature algorithm is used as the default encryption algorithm; Based on the preset encryption algorithm, obtain a key pair including a public key and a private key; Using the private key, digitally sign the initial access token, append the generated digital signature to the preset position of the initial access token, and obtain the target access token; The target access token is sent to the client so that the client can verify the digital signature in the target access token based on the public key and using a preset encryption algorithm. If the verification is successful, the target access token is considered safe and is attached to the authorization request to request access to the resource to be accessed owned by the user.

2. The resource access method with enhanced token security based on OAuth2.0 according to claim 1, characterized in that: The method of selecting a corresponding preset encryption algorithm according to the token security vulnerability includes selecting the elliptic curve public key cryptography algorithm SM2 as the preset encryption algorithm when the token security vulnerability includes a man-in-the-middle attack and a replay attack: Based on the elliptic curve public key cryptography algorithm SM2, using Generate a key pair consisting of a public key and a private key; based on , using the private key, digitally sign the initial access token, attach the generated digital signature to the preset position of the initial access token, and obtain the target access token; The target access token is sent to the client so that the client can verify the digital signature in the target access token based on the public key and use the elliptic curve public key cryptography algorithm SM2 to obtain a Boolean value. If the Boolean value is True, the target access token is considered safe and the target access token is attached to the authorization request to request access to the resource to be accessed owned by the user.

3. The resource access method with enhanced token security based on OAuth2.0 according to claim 2, characterized in that: The utilization Generate a key pair consisting of a public key and a private key, including: Preset elliptic curve It is defined in a finite field On the elliptic curve, for a given security parameter , select , are the parameters of the elliptic curve equation, It is an elliptic curve on Step base point, are the coordinates of the base point; Using the SM3 hash function and random number generator, with the server as the signer, a private key is randomly generated, expressed as: , , Represents an elliptic curve The order of Based on the private key, the corresponding public key is calculated using the preset elliptic curve and base point, which is expressed as: .

4. The resource access method with enhanced token security based on OAuth2.0 according to claim 3, characterized in that: The based , using the private key, digitally sign the initial access token, attach the generated digital signature to the preset position of the initial access token, and obtain the target access token, including: S41: Based on the resource to be accessed , get the length Bit signer ID , and convert it into two bytes to get a two-byte identifier ; S42: The server calculates the identity, which is expressed as: ; S43: Select a random number , multiply with the base point to get the private key ; S44: Using SM3 hash function, the identity , resources to be accessed , and the x-coordinate of the private key , calculate and obtain the hash value, expressed as: , ; S45: If the hash value satisfy or , then return to step S43 and reselect the random number , until the hash value satisfy and , then calculate the signature value, expressed as: ; S46: If the signature value , then return to step S43 and reselect the random number , until the signature value , S47: Append the signature value to the header of the initial access token to obtain the target access token.

5. The resource access method with enhanced token security based on OAuth2.0 according to claim 4, characterized in that: The target access token is sent to the client so that the client can verify the digital signature in the target access token based on the public key using the elliptic curve public key cryptography algorithm SM2 to obtain a Boolean value. If the Boolean value is True, the target access token is considered safe and the target access token is attached to the authorization request to request access to the resource to be accessed owned by the user, including: The client receives the target access token and public key; use Verify that the digital signature in the target access token is correct, including: For resources to be accessed whose digital signatures are to be verified , its signature content ,like , the verification fails; like , then calculate , ,like , the verification fails; like , then calculate , ,like , then the verification is passed and output is 1, otherwise the verification fails and output is 0; If the verification is successful, the target access token is considered safe and is attached to the authorization request to request access to the resource to be accessed owned by the user; in, Indicates the resource to be accessed whose digital signature is to be verified. Indicates the signature content, consisting of two parts and , expressed as .

6. The resource access method with enhanced token security based on OAuth2.0 according to claim 1, characterized in that: The method of selecting a corresponding preset encryption algorithm according to the token security vulnerability includes using the lattice signature algorithm as the preset encryption algorithm when the token security vulnerability includes a quantum computing threat: Based on the lattice signature algorithm, using Generate public parameters; Based on public parameters, using Generate a key pair consisting of a public key and a private key; based on , using the private key, digitally sign the initial access token, attach the generated digital signature to the preset position of the initial access token, and obtain the target access token; Send the target access token to the client so that the client can use the lattice signature algorithm based on the public key , the digital signature in the target access token is verified. If the verification matches, the target access token is considered safe and the target access token is attached to the authorization request to request access to the resource to be accessed owned by the user.

7. The resource access method with enhanced token security based on OAuth2.0 according to claim 6, characterized in that: The lattice signature algorithm is based on Generate common parameters, including: Default positive integer 、 、 、 , randomly select a prime number ,satisfy and ; calculate: , , , , ; Randomly select a positive integer ,make ,calculate ; Select a positive integer ,calculate: ； ； ； ； Get public parameters: ; in, For collection An element in Represented in the set of integers Random sampling, Representing a collection Any element in represents a natural number, Represents from the set The matrix is ​​randomly selected uniformly in .

8. The resource access method with enhanced token security based on OAuth2.0 according to claim 7, characterized in that: Based on the public parameters, Generate a key pair consisting of a public key and a private key, including: Based on common parameters, select from: , , , ; use Get the public key and private key, respectively: , ; in, Represents a collection The matrix is ​​randomly selected uniformly in Represents a collection The matrix is ​​randomly selected uniformly in .

9. The resource access method with enhanced token security based on OAuth2.0 according to claim 8, characterized in that: The based , using the private key, digitally sign the initial access token, attach the generated digital signature to the preset position of the initial access token, and obtain the target access token, including: Enter plain text , public key With integers ; calculate: , , ; , represents the sampling algorithm; ; Output digital signature: ; The generated digital signature is appended to the preset location of the initial access token to obtain the target access token.

10. The resource access method with enhanced token security based on OAuth2.0 according to claim 9, characterized in that: The target access token is sent to the client so that the client can use the lattice signature algorithm based on the public key. , verify the digital signature in the target access token. If the verification matches, the target access token is considered safe and attached to the authorization request, requesting access to the resource to be accessed owned by the user, including: The client receives the target access token and public key; Enter the public key , plain text , digital signature and public parameters ; calculate: ， ； Output ; like , the verification fails; if , if the verification matches, the target access token is considered safe, and the target access token is attached to the authorization request to request access to the resource to be accessed owned by the user.

Images