Anti-quantum security enhancement method for open authorization protocol

Abstract

The invention discloses an anti-quantum security enhancement method for an open authorization protocol, and particularly relates to the technical field of quantum security. Extracting an anti-quantum public key for signature, trust chain information of the anti-quantum public key and JWT content to generate a public key binding fingerprint, embedding the public key binding fingerprint into a JWT head, and signing together with the public key binding fingerprint; after the verification end receives the JWT, analyzing the head of the JWT, and extracting a signature algorithm field, a public key identifier and a PBTF field; pulling a corresponding public key from a local cache or a preset key endpoint according to the kid field, and performing structure and format verification; multi-dimensional trust evaluation is carried out on the pulled public key, a total risk score is calculated, and the JWT request is divided into a low-risk level, a medium-risk level and a high-risk level according to a scoring result, which are respectively corresponding to release, limitation or rejection processing strategies, so that a strong binding verification mechanism between the JWT content and the signature public key source is realized; and the signature credibility and the risk control capability of the open authorization protocol system in the quantum encryption resisting environment are obviously enhanced.

Description

Technical Field

[0001] The present invention relates to the field of quantum - secure technologies, and particularly to a method for enhancing the quantum - secure resistance of the Open Authorization protocol. Background Art

[0002] Enhancing the quantum - secure resistance of the Open Authorization protocol means introducing quantum - resistant cryptographic algorithms on the basis of the currently widely used Open Authorization (OAuth) protocol to resist the cracking threat of future quantum computing to traditional encryption methods (such as RSA, ECDSA), so as to ensure that the user identity authentication and authorization processes still have sufficient security in the quantum - computing environment. Such enhancements usually involve using quantum - resistant algorithms such as lattice cryptography and hash - based signatures to replace or supplement existing key - exchange, signature, and encryption mechanisms.

[0003] The existing technologies have the following deficiencies: When using a quantum - resistant signature algorithm to transform the JWT verification mechanism, if the system only automatically pulls the corresponding JWK public key from the authorization server based on the kid field in the JWT during signature verification and does not effectively authenticate the source of the public key (such as certificate - chain verification or trusted - signature binding), there is a serious risk of the public - key source being replaced by an attacker. The attacker can forge a pair of quantum - resistant public and private keys, sign a forged JWT with the private key, then construct a JWK containing the public key and deploy it to a fake authorization server or contaminate the cache, causing the verification end to erroneously pull and trust the forged public key, thereby bypassing the signature verification of illegal tokens and ultimately impersonating a legitimate user in the system, which is extremely harmful. Summary of the Invention

[0004] The purpose of the present invention is to provide a method for enhancing the quantum - secure resistance of the Open Authorization protocol to solve the deficiencies in the background art.

[0005] To achieve the above - mentioned purpose, the present invention provides the following technical solution: A method for enhancing the quantum - secure resistance of the Open Authorization protocol, including: Obtain the public key of the quantum - resistant encryption algorithm for signature and its trust - chain information, calculate the digest value of the public - key trust chain and the JWT token content, and generate the Public - Key Binding Fingerprint (PBTF); Embed the PBTF as a part of the JWT header and sign it together; after the verification end receives the JWT, parse the JWT and extract the signature - algorithm field, the public - key identifier field kid, and the PBTF field in its header; According to the kid field, pull the corresponding public key from the preset key - distribution endpoint; conduct multi - dimensional trust evaluation on the pulled public key, including calculating the Trust - Path Authentication Level (TPAL) of the public - key trust path and the Key - Behavior Consistency Score (KBCS); Recalculate the PBTF* value based on the extracted JWT payload content and the fetched public key trust chain, and compare its consistency with the PBTF embedded in the JWT; Construct a risk scoring model and comprehensively calculate the risk value R. The expression is: ; where is the weighting coefficient, and δ is the boolean penalty function; Based on the risk value R, determine whether the public key used by the current JWT is trustworthy and make a decision according to the preset threshold.

[0006] Preferably, the generation of the public key binding fingerprint PBTF includes: Normalize the trust chain information of the quantum-resistant public key used for signing, including its superior certificate, public key source identifier, or registration transparency log entry, to obtain a standardized trust chain data structure; Combine the standardized trust chain data structure with the payload content and header content of the JWT token to construct a data body to be bound; Perform a digest calculation on the data body to be bound using a preset hash algorithm to obtain fingerprint data; Insert the fingerprint data as the public key binding fingerprint PBTF into the extension field of the JWT header, and perform a quantum-resistant signature algorithm signature process together with the header and payload.

[0007] Preferably, the parsing process after the verification end receives the JWT includes: Parse the received JWT token, separate the header, payload, and signature into three parts according to the dot-separated structure, perform base64url decoding on the header part to obtain a structured JSON data object; from the header JSON object, extract the key fields: the field alg representing the signature algorithm, the field kid representing the public key identifier, and the public key binding fingerprint field pbtf.

[0008] Preferably, the pulling of the corresponding public key from the preset key distribution endpoint according to the kid field includes: reading the kid field in the JWT header and parsing out the corresponding public key unique identifier; checking whether there is a public key record corresponding to the kid in the local cache. If a hit is found, extract the public key and continue the subsequent processing. If no hit is found, proceed to the next step; initiate a secure connection request to the preset key distribution endpoint to pull the public key information matching the kid. The connection needs to be verified through the TLS certificate chain; perform a structural verification on the pulled public key information to confirm that it meets the expected quantum-resistant key format requirements.

[0009] Preferably, the calculation steps of the trust path authentication level TPAL include: Obtain the public key record that matches the kid from the key distribution endpoint, and parse the trust chain information therein. The trust chain information includes the superior certificate signature, the key registration authority identifier, and the key transparency log entry; Verify the trust chain information item by item, including verifying whether the certificate signature is valid, whether the key registration identifier is in the trusted list, and whether the key exists in the transparency log or the blockchain registration record; Assign weighted scores to the verified trust factors, including 40 points for successful certificate signature verification, 30 points for hitting the key whitelist, and 30 points for the existence of the transparency log. The total score is set to 100 points; Take the obtained weighted total score as the trust path authentication level TPAL of the public key.

[0010] Preferably, the calculation steps of the public key behavior consistency score KBCS include: Query the usage records of the public key associated with the current kid in the system over a past period of time, and extract the signing frequency, signing time distribution, signing purpose domain name, and historical change times; Set a behavior benchmark model for each behavior parameter, including that the average daily signing does not exceed 50 times as normal, the purpose domain name does not exceed 2 as stable, and the kid does not change within one month as having high consistency; Compare the behavior parameters of the current public key with the benchmark model, and score according to the deviation degree, including deducting 30 points for exceeding the frequency limit, 20 points for excessive use diversity, and 50 points for frequent changes; Sum up the deduction results and take the inverse of 100 as the behavior consistency score KBCS of the current public key.

[0011] Preferably, calculating the PBTF* value and comparing its consistency with the PBTF embedded in the JWT includes: Read and parse the payload content in the JWT, and extract the complete trust chain information from the public key record pulled by the verification end, including components such as the superior certificate, registration identifier, and key registration path, to construct a structured trust chain data body; Perform an ordered splicing of the structured trust chain data body and the payload content of the JWT to construct a bound data body; Perform a hash calculation on the constructed bound data body using a preset digest function to generate the PBTF* fingerprint value. The calculation process is: input the spliced data body into the digest function to obtain a fixed-length digest value as the PBTF*; Compare the calculated PBTF* value with the PBTF field value originally embedded in the JWT Header. If they are consistent, it is confirmed that the JWT has not been tampered with and the public key used is from a trusted source. If they are inconsistent, mark the current signature verification process as a high-risk state and trigger an exception response mechanism.

[0012] Preferably, where δ is a Boolean penalty function, if the bound fingerprints are consistent, the penalty term is 0; if they are inconsistent, the penalty term is set to a fixed value, and R ranges from 0 to 100.

[0013] Preferably, according to the interval in which the R value falls, determine the trust level and processing strategy: if R is less than or equal to 30, it indicates safe and trustworthy; if R ranges from 30 to 50, it indicates medium risk; if R is greater than 50, it indicates high risk and rejects verification.

[0014] In the above technical solution, the technical effects and advantages provided by the present invention are as follows: 1. By introducing the public key binding fingerprint mechanism, the present invention strongly binds the business payload of the JWT to the public key trust chain used for signature, solving the problems in the prior art that the verification end cannot judge the authenticity of the public key and is easily bypassed by forged keys for signature verification. At the same time, by recalculating PBTF* at the verification end and comparing it with the original PBTF for consistency, the structural integrity and anti-tampering ability of the signature verification process are effectively enhanced, which is particularly suitable for complex trust environments that support quantum-resistant signature algorithms.

[0015] 2. The present invention proposes a multi-dimensional trust evaluation mechanism and constructs a comprehensive risk scoring model that combines TPAL (Trust Path Authentication Level), KBCS (Behavior Consistency Score), and PBTF comparison results. This model supports dynamic risk judgment for each JWT request and executes differentiated security policies based on the scoring results, thus realizing the leap from the static verification of "whether the signature passes" to the structured decision-making of "whether it is overall trustworthy", significantly enhancing the system's defense capabilities against quantum computing threats and trust source pollution attacks. Description of the Drawings

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments recorded in the present invention, and those of ordinary skill in the art can also obtain other drawings based on these drawings.

[0017] Figure 1 It is the method mind map of the present invention. Detailed Embodiments

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0019] For the embodiments, please refer to Figure 1 As shown, the method for enhancing the quantum-resistant security of the open authorization protocol in this embodiment includes: Obtain the public key of the quantum-resistant encryption algorithm for signature and its trust chain information, calculate the digest value of the public key trust chain and the JWT token content, and generate the public key bound fingerprint PBTF; Embed the PBTF as a part of the JWT header and sign it together; after receiving the JWT at the verification end, parse the JWT and extract the signature algorithm field, public key identifier field kid, and PBTF field in its header; According to the kid field, pull the corresponding public key from the preset key distribution endpoint; perform multi-dimensional trust evaluation on the pulled public key, including calculating the public key trust path authentication level TPAL and the public key behavior consistency score KBCS; Based on the extracted JWT payload content and the pulled public key trust chain, recalculate the PBTF* value and compare its consistency with the PBTF embedded in the JWT; Use the trust path authentication level TPAL, behavior consistency score KBCS, and the public key bound fingerprint consistency verification result as inputs together to construct a comprehensive risk scoring model, and comprehensively calculate the risk value R. The expression is: ; where is the weighting coefficient, and δ is the Boolean penalty function; Based on the risk value R, determine whether the public key used by the current JWT is trustworthy and make a decision according to the preset threshold.

[0020] During the process of generating the JWT by the authorization server, the method for generating and embedding the PBTF provided by the present invention includes the following four steps: First, before generating the JWT signature, the authorization server obtains the public key for signature and its corresponding trust chain information. This trust chain may include, but is not limited to: The digital certificate of the superior issuer; The key registration record of the affiliated institution; The public key transparency log record (such as Key Transparency Log); The unique identifier of the public key source, such as the URL endpoint of the JWK Set.

[0021] For the convenience of subsequent abstract calculation and consistency verification, it is necessary to uniformly format the above information and construct it into a standardized trust chain data structure. For example, it can be represented by a JSON object or a structured binary encoding, including fields such as the hash value, issuance time, issuing agency, JWK source address, etc. of each level of certificate, and arranged in a fixed order to ensure cross-system consistency.

[0022] After the construction of the header and payload of the JWT is completed, the present invention combines the trust chain data structure with the content of the JWT to construct a bound data body for generating the PBTF. The bound data body can adopt the following structure: Standardized sequence of the trust chain structure; The header field of the JWT; The payload field of the JWT; Optional system environment parameters (such as issuer identifier, issuance timestamp, etc.).

[0023] Through the ordered combination of the bound data body, the generation of the PBTF is not only strongly bound to the public key used, but also closely related to the content of the JWT itself, eliminating the risk of PBTF forgery after the token content is replaced.

[0024] For the above bound data body, a hash calculation is performed using a digest algorithm with strong collision resistance and quantum attack resistance to generate a unique and irreversible PBTF value. The digest algorithm can include: SHA-512; BLAKE3; or a quantum-resistant digest algorithm compatible with lattice cryptography design.

[0025] The generation process of the PBTF can be described as: "Using the selected hash function, perform a digest calculation on the combined data body of the trust chain data, JWT header, and payload to obtain a fixed-length digest result as the public key binding fingerprint PBTF." The PBTF value should have the following characteristics: A small change in the input will result in a completely different output (anti-forgery); it is impossible to reverse-engineer the public key or the original data from the PBTF (anti-reverse); the result length is fixed (suitable for embedding in the JWT header); it can be generated consistently across environments (facilitating recalculation at the verification end).

[0026] After generating the PBTF value, it is embedded as a new field into the header of the JWT. Subsequently, the authorization server uses a quantum-resistant signature algorithm (such as Dilithium, Falcon) to sign the header and payload, ensuring that the PBTF field is protected together with the JWT content and cannot be tampered with. In actual system deployment, PBTF can also be processed with base64url encoding in conjunction with the compact JWT encoding method to ensure compatibility.

[0027] JWT is a token represented in a three-part structure. After receiving the JWT, the verification end first splits the entire JWT string by the dot to obtain three parts of content. Then it decodes the Header part with base64url to obtain the header data object in JSON format.

[0028] From the header data, the verification end extracts the following fields and processes them separately: Signature algorithm field alg: It is used to indicate the quantum-resistant encryption algorithm used for signing, such as "DILITHIUM2", "FALCON512", etc. This field is used to select the appropriate signature verifier subsequently.

[0029] Public key identifier field kid: It is used to identify the public key used for signing, usually corresponding to a certain record in the JWK set (JSON Web Key Set) of the authorization server, and is used to find the specific public key from a remote endpoint or local cache.

[0030] Public key bound fingerprint field pbtf: This field is the key extension field proposed by the present invention, representing the hash fingerprint value after binding the signature public key trust chain with the JWT content, and is an auxiliary credential to ensure that the JWT has not been replaced and the public key source is trustworthy.

[0031] To prevent an attacker from forging a pbtf field that is structurally similar but has illegal content, after extracting the pbtf field, the present invention should also perform semantic and structural legality verification on the value of this field, including but not limited to: Whether the field exists; whether the field length is consistent with the expected output length of the digest algorithm (for example, the output of SHA-512 is 512 bits, that is, 64 bytes, and after base64url encoding, it is about 86 characters); Whether it consists of valid characters to avoid injecting malicious scripts or binary residues; Whether it is compatible with the signature algorithm declared in the JWT. For example, for a JWT signed with the "DILITHIUM2" algorithm, a quantum-resistant secure digest function (such as SHA-512, BLAKE3) should be used to generate pbtf.

[0032] Only after the above verification passes can the system send the pbtf field to the subsequent fingerprint reconstruction and consistency verification process.

[0033] After the verification end receives the JWT, it first needs to parse the header content of the JWT. The header part is a JSON data structure encoded by base64url, which contains fields such as alg, typ, and kid.

[0034] The system reads the kid field and extracts the corresponding public key unique identifier. For example, this identifier can be the Key ID of a certain JSON Web Key or a sub-segment of the URI identifier.

[0035] The pulling process includes the following steps: Local cache matching: The system first checks whether there is a public key record matching the kid in the local cache; if a hit is found, the public key is directly extracted for subsequent verification, thereby improving the response speed and offline availability.

[0036] Remote key endpoint pulling: If the local cache miss occurs, the system will construct an HTTPS request and initiate a connection request to the preset key publishing endpoint, for example: This request must pass through the TLS secure channel, and it is necessary to verify whether the certificate chain of the server side is trusted to prevent man-in-the-middle attacks or forged server responses.

[0037] Structure verification and filtering: The pulled JWK data is a set of public key JSON objects. The system needs to perform structural verification on the items matching the kid among them to confirm whether they conform to the currently supported post-quantum key format specification, such as whether they have keyword fields such as kty, alg, x, and crv, and whether they use supported post-quantum algorithms (such as Dilithium, Falcon).

[0038] Error handling and policy response: If the verification fails or the connection is abnormal, the system records the relevant event logs and rejects the signature verification or switches to an alternative key source according to the configured policy.

[0039] Once the public key is successfully pulled, it is necessary to further perform a structured assessment of its trustworthiness. TPAL (Trust Path Assurance Level) is used to measure the authentication integrity of the public key in the trust chain, and the scoring range is from 0 to 100. The higher the score, the higher the trustworthiness.

[0040] The calculation steps are as follows: Trust factor extraction: Parse the trust chain information carried by the public key. The trust chain can include: The digital certificate of the superior issuer (certificate signature); The unique identifier of the key registration authority (such as DID, CA ID); An entry in the Key Transparency log; The key declaration record in the blockchain or the trusted audit system.

[0041] Factor verification logic: If the certificate signature is verified through the trusted root certificate chain, it is recorded as "valid"; If the registration authority identifier exists in the system-predefined whitelist, it is recorded as "hit"; If there is a corresponding Hash record in the key transparency log and it has not been revoked, it is recorded as "exists".

[0042] Weighted scoring rule: If the certificate signature verification is successful, 40 points are assigned; If the registration identifier is hit, 30 points are assigned; If the key transparency log exists, 30 points are assigned.

[0043] TPAL calculation result: The system sums up the scores obtained from the above factors to obtain a trust path authentication level TPAL between 0 and 100. For example: If the certificate verification is successful and the transparency log exists, but the registration identifier is not hit, then the TPAL is 70 points.

[0044] TPAL measures "static credibility", while KBCS (Key Behavior Consistency Score) is used to evaluate the "behavior consistency" of this public key in historical use to help identify "pseudo-legitimate keys" implanted by long-term potential attackers.

[0045] The scoring steps are as follows: Behavior parameter extraction: Issuance frequency (such as the number of issuances in the past 7 days); Issuance time distribution (whether it is concentrated in a certain time period); Used purpose domain names (the number of service domain names signed by this public key); Historical change times (whether the kid has recently changed the pointed public key frequently); Benchmark behavior model setting: The number of daily issuances not exceeding 50 times is "normal"; Using no more than 2 purpose domain names is "stable"; Not changing the kid within one month is "high consistency".

[0046] Deviation scoring mechanism: The system compares the current actual behavior with the benchmark model: If the signing times exceed the upper limit, 30 points will be deducted; If the number of domain names for use exceeds the threshold, 20 points will be deducted; If frequent changes occur, 50 points will be deducted.

[0047] KBCS calculation method: Sum up the above deduction results, and then subtract the total deducted points from 100 to get the final KBCS. Example: If the public key deviates in terms of behavior frequency and usage, 50 points will be deducted, then KBCS = 100 - 50 = 50.

[0048] After the verification end receives the JWT, the system executes the calculation and comparison process of PBTF*, which mainly includes the following steps: The system first parses the JWT structure and divides it into three parts: the header (Header), the payload (Payload), and the signature (Signature). Specifically: Perform base64url decoding on the Header and Payload respectively; Extract the pbtf field from the Header, that is, the public key binding fingerprint embedded by the issuing end; Extract the core business data of the JWT (such as fields like sub, iat, iss, exp, etc.) from the Payload; Extract the trust chain data from the previously pulled public key records, including but not limited to: The superior CA signature certificate chain; The public key registration source identifier; The registration information of the public key in Key Transparency or the blockchain.

[0049] The above data constitutes the basic data set required for PBTF* reconstruction.

[0050] To ensure the verifiability and cross-platform consistency of the PBTF calculation result, the extracted trust chain data and Payload content must be combined into a standardized data body. The specific rules include: Fixed order: Arrange various fields in a preset order, such as trust chain items first and Payload fields later; Standard format: Uniformly encode all field contents in JSON or CBOR, and mixing is prohibited; Field delimiter: Use a clear delimiter (such as the field name enclosed in double quotes and the colon) to ensure no ambiguity in the structure; Character set limitation: Uniformly use UTF-8 encoding to avoid deviation of the digest value due to character set differences.

[0051] For the constructed data body, the system uses the specified digest algorithm to perform hash calculation to generate the PBTF* fingerprint value. The selectable digest algorithms include: SHA-512 (recommended default algorithm, suitable for most general platforms); BLAKE3 (for high-performance concurrent scenarios); Can be replaced with a quantum-resistant digest algorithm (such as the hash function used in SPHINCS+) to meet the requirements of post-quantum cryptography.

[0052] The digest calculation process is as follows: Convert the bound data body into a byte stream and input it into the digest function to generate a digest value of a fixed length (such as 512 bits), which is the PBTF*.

[0053] The calculation process is described in words as follows: Using the set hash function, take the bound data body constructed in step 2 as the input, and the calculated fixed-length digest value is called PBTF*, which is used to represent the combined fingerprint of the current JWT content and the trust chain.

[0054] The system compares the PBTF* calculated in the above steps byte by byte with the pbtf field embedded in the JWT Header. If the two are exactly the same, it means that the Payload content of this JWT does indeed match the declared public key source, has not been tampered with, and the signer has not been replaced. If the two are inconsistent, the following security risks may exist: The JWT Payload has been replaced or tampered with after issuance; the public key pointed to by the kid used in the JWT is not the actual signing key; the authorization server has been contaminated or misused at the public key distribution endpoint; an attacker has forged the PBTF but failed to reconstruct the real hash structure.

[0055] In this case, the system should mark this signature verification process as "failed" or "suspicious", and execute the next processing strategy according to the overall risk scoring model (combining TPAL and KBCS), such as denying access, logging, or notifying the administrator.

[0056] The calculation formula for the total risk score R is as follows (described in words): Subtract the score of the trust path authentication level TPAL from 100 as the "lack of trust degree" of this path; then multiply it by the first weight coefficient; then multiply the behavior consistency score KBCS by the second weight coefficient; finally, add a fingerprint consistency penalty term, the value of which depends on whether the verification end detects PBTF inconsistency; the sum of the three constitutes the total risk score R, and the value range is set between 0 and 100, and the larger the value, the higher the risk. Specifically expressed as: ; where, are the weighting coefficients, and δ is the Boolean penalty function; where: TPAL is the public key trust path authentication level, with a full score of 100 points, and the higher the score, the more trustworthy; KBCS is the public key behavior consistency score, and the higher the value, the more abnormal the behavior; The fingerprint inconsistency penalty term takes values in two cases: If PBTF is consistent with the recalculated PBTF*, the value of this term is 0; if the two are inconsistent, this term can be a fixed value (such as 50), or a weighted value (such as 30 - 70) can be calculated based on factors such as the historical error frequency and PBTF difference degree; The weight coefficients can be flexibly configured according to the deployment environment. For example: weight one is set to 0.5; weight two is set to 0.3; weight three is set to 0.2; so that the scoring mechanism can not only respond to the weakening of the trust chain, but also identify the risks of abnormal behavior and structural tampering.

[0057] Based on the calculated R value, the system can automatically divide the current verification scenario into different trust levels and perform corresponding processing actions: Low risk (R ≤ 30): It means that the public key trust chain of the JWT signature is complete, the historical behavior is consistent, and the PBTF verification passes; it can be regarded as a trusted request, and the signature verification is normally completed and access to resources is allowed.

[0058] Medium risk (30 < R ≤ 50): It means that there is a slight weakening of trust or a deviation in behavior in the JWT; the system can record security audit logs, prompt the administrator to pay attention, or execute a downgrading policy on the request (such as only allowing read-only access).

[0059] High risk (R > 50): It means that there are serious trust defects, abnormal behavior, or fingerprint tampering detected in the public key used by the JWT; the system should immediately interrupt the verification process, reject the request for access, and trigger a security event reporting mechanism to prevent potential forgery attacks.

[0060] The above formulas are all dimensionless and take their numerical values for calculation. The formulas are obtained by collecting a large amount of data for software simulation to get a formula closest to the actual situation. The preset parameters in the formulas are set by technicians in this field according to the actual situation.

[0061] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more collections of available media. The available media can be magnetic media (such as floppy disks, hard disks, magnetic tapes), optical media (such as DVDs), or semiconductor media. The semiconductor media can be a solid-state drive.

[0062] It should be understood that the term "and / or" in this document is merely a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. Here, A and B can be singular or plural. In addition, the character " / " in this document generally represents an "or" relationship between the associated objects before and after, but it may also represent an "and / or" relationship, which can be specifically understood by referring to the context. Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed in this document can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0063] As described above, the above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present application can easily think of changes or substitutions, which should all be covered by the protection scope of the present application.

Claims

1. Anti-Quantum Security Enhancement Method for Open Authorization Protocols, characterized in that: Including: Obtain the public key of the quantum-resistant encryption algorithm for signature and its trust chain information, calculate the digest value of the public key trust chain and the JWT token content, and generate the public key bound fingerprint PBTF; Embed the PBTF as a part of the JWT header and sign it together; after receiving the JWT at the verification end, parse the JWT and extract the signature algorithm field, public key identifier field kid, and PBTF field in its header; Pull the corresponding public key from the preset key distribution endpoint according to the kid field; Perform multi-dimensional trust assessment on the retrieved public key, including calculating the authentication level of the public key trust path and the public key behavior consistency score ; Based on the extracted JWT payload content and the pulled public key trust chain, recalculate the PBTF* value and compare its consistency with the PBTF embedded in the JWT; Build a risk scoring model and comprehensively calculate the risk value R, with the expression: ; where is the weighting coefficient, and δ is the Boolean penalty function; Judge whether the public key used by the current JWT is trustworthy based on the risk value R and make a decision according to the preset threshold.

2. The anti-quantum security enhancement method for the open authorization protocol according to claim 1, characterized in that: The generation of the public key bound fingerprint PBTF includes: Normalize the trust chain information of the quantum-resistant public key for signature, including its superior certificate, public key source identifier, or registration transparency log entry, to obtain a standardized trust chain data structure; Combine the standardized trust chain data structure with the payload content and header content of the JWT token to construct a data body to be bound; Perform digest calculation on the data body to be bound using a preset hash algorithm to obtain fingerprint data; Insert the fingerprint data as the public key bound fingerprint PBTF into the extension field of the JWT header and perform quantum-resistant signature algorithm signature processing together with the header and payload.

3. The anti-quantum security enhancement method for the open authorization protocol according to claim 1, characterized in that: The parsing process after receiving the JWT at the verification end includes: Parse the received JWT token, separate the header, payload, and signature into three parts according to the dot-separated structure, perform base64url decoding on the header part to obtain a structured JSON data object; from the header JSON object, extract the key fields: the field alg representing the signature algorithm, the field kid representing the public key identifier, and the public key bound fingerprint field pbtf.

4. The anti-quantum security enhancement method for the open authorization protocol according to claim 1, wherein: Pull the corresponding public key from the preset key distribution endpoint according to the kid field includes: read the kid field in the JWT header and parse the corresponding public key unique identifier; check whether there is a public key record corresponding to the kid in the local cache, if hit, extract the public key and continue the subsequent processing, if not hit, go to the next step; initiate a secure connection request to the preset key distribution endpoint to pull the public key information matching the kid, and the connection needs to be verified through the TLS certificate chain; perform structure verification on the pulled public key information to confirm that it meets the expected quantum-resistant key format requirements.

5. The anti-quantum security enhancement method for an open authorization protocol according to claim 4, characterized in that: The calculation steps of the trust path authentication level TPAL include: Obtain the public key record matching the kid from the key distribution endpoint and parse the trust chain information therein, where the trust chain information includes superior certificate signature, key registration agency identifier, and key transparency log entry; Verify the trust chain information item by item, including verifying whether the certificate signature is valid, whether the key registration identifier is in the trusted list, and whether the key exists in the transparency log or blockchain registration record; Assign weighted scores to the verified trust factors, including 40 points for successful certificate signature verification, 30 points for hitting the key whitelist, and 30 points for the existence of the transparency log, with the total score set at 100 points; Use the obtained weighted total score as the trust path authentication level TPAL of the public key.

6. The anti-quantum security enhancement method for the open authorization protocol according to claim 5, characterized in that: The calculation steps of the public key behavior consistency score KBCS include: Query the usage records of the public key associated with the current kid in the system over a past period of time, and extract the signing frequency, signing time distribution, signing purpose domain names, and historical change times; Set a behavior benchmark model for each behavior parameter, including no more than 50 signatures per day on average as normal, no more than 2 purpose domain names as stable, and no change of kid within one month as high consistency; Compare the behavior parameters of the current public key with the benchmark model and score according to the deviation degree, including deducting 30 points for exceeding the frequency limit, 20 points for excessive purpose diversity, and 50 points for frequent changes; Sum up the deduction results and take the inverse of 100 as the behavior consistency score KBCS of the current public key.

7. The anti-quantum security enhancement method for the open authorization protocol according to claim 6, characterized in that: The calculation of the PBTF* value and the consistency comparison with the PBTF embedded in the JWT include: Read and parse the payload content in the JWT, and extract the complete trust chain information from the public key records pulled from the verification end, including the superior certificate, registration identifier, and key registration path components, to construct a structured trust chain data body; Sequentially splice the structured trust chain data body with the payload content of the JWT to construct a bound data body; Perform a hash calculation on the constructed bound data body using a preset digest function to generate a PBTF* fingerprint value, where the calculation process is: input the spliced data body into the digest function to obtain a fixed-length digest value as PBTF*; Perform a consistency comparison between the calculated PBTF* value and the original embedded PBTF field value in the JWT Header. If they are consistent, confirm that the JWT has not been tampered with and the public key used is from a trusted source. If they are inconsistent, mark the current signature verification process as a high-risk state and trigger an exception response mechanism.

8. The anti-quantum security enhancement method for the open authorization protocol according to claim 1, wherein: Among them, δ is a boolean penalty function. If the bound fingerprints are consistent, the penalty term is 0; if they are inconsistent, the penalty term is set to a fixed value, and R ranges from 0 to 100.

9. The anti-quantum security enhancement method for the open authorization protocol according to claim 1, characterized in that: Determine the trust level and handling strategy according to the interval in which the R value falls: if R is less than or equal to 30, it indicates safe and trustworthy; if R is between 30 and 50, it indicates medium risk; if R is greater than 50, it indicates high risk and reject the verification.

Images