Quantum-resistant security enhancement methods for open licensing protocols

Abstract

The present invention discloses a method for enhancing the quantum security of an open authorization protocol, which specifically relates to the field of quantum security technology. The method comprises extracting the quantum-resistant public key used for signing and its trust chain information and JWT content to generate a public key binding fingerprint, embedding the fingerprint into the JWT header and signing the fingerprint together. After receiving the JWT at the verification end, the method parses its header to extract the signature algorithm field, public key identifier and PBTF field. According to the kid field, the corresponding public key is pulled from the local cache or preset key endpoint, and the structure and format are verified. A multi-dimensional trust assessment is performed on the pulled public key to calculate the total risk score. According to the score result, the JWT request is divided into low risk, medium risk and high risk levels, which correspond to release, restriction or rejection processing strategies respectively. The method realizes a strong binding verification mechanism between the JWT content and the signature public key source, and significantly enhances the signature credibility and risk control capability of the open authorization protocol system in a quantum-resistant encryption environment.

Description

Technical Field

[0001] The present invention relates to the field of quantum security technology, and in particular to a method for enhancing the anti-quantum security of an open authorization protocol. Background Art

[0002] Quantum-resistant security enhancements to open authorization protocols refer to the introduction of quantum-resistant cryptographic algorithms into the currently widely used Open Authorization (OAuth) protocol. This approach aims to mitigate the potential threat of quantum computing cracking traditional encryption methods (such as RSA and ECDSA), thereby ensuring that user authentication and authorization processes remain sufficiently secure in a quantum computing environment. These enhancements typically involve the use of quantum-resistant algorithms such as lattice cryptography and hash signatures to replace or supplement existing key exchange, signature, and encryption mechanisms.

[0003] The existing technology has the following shortcomings:

[0004] When using quantum-resistant signature algorithms to improve the JWT verification mechanism, if the system automatically pulls the corresponding JWK public key from the authorization server based solely on the kid field in the JWT during signature verification, without validly authenticating the source of the public key (such as certificate chain verification or trusted signature binding), there is a serious risk of an attacker replacing the public key source. An attacker could forge a quantum-resistant public-private key, use that private key to issue a forged JWT, then construct a JWK containing that public key and deploy it to a counterfeit authorization server or contaminate the cache, causing the verifier to mistakenly pull and trust the forged public key, thereby bypassing signature verification for the illegitimate token and ultimately impersonating a legitimate user in the system, causing significant harm. Summary of the Invention

[0005] The purpose of the present invention is to provide a method for enhancing the anti-quantum security of an open authorization protocol to address the shortcomings of the background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for enhancing quantum security of an open licensing protocol, comprising:

[0007] Obtain the public key of the quantum-resistant encryption algorithm used for signing 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;

[0008] Embed the PBTF as part of the JWT header and sign it together. After receiving the JWT, the verification end parses the JWT and extracts the signature algorithm field, public key identifier field kid, and PBTF field in its header.

[0009] Pull the corresponding public key from the preset key publishing endpoint based on the kid field; perform a multi-dimensional trust assessment on the pulled public key, including calculating the public key trust path authentication level (TPAL) and the public key behavior consistency score (KBCS);

[0010] Based on the extracted JWT payload content and the pulled public key trust chain, the PBTF* value is recalculated and compared with the PBTF embedded in the JWT for consistency;

[0011] Construct a risk scoring model and comprehensively calculate the risk value R, which is expressed as: ;in, is the weighting coefficient, δ is the Boolean penalty function;

[0012] Based on the risk value R, it is determined whether the public key used by the current JWT is credible, and a decision is made according to a preset threshold.

[0013] Preferably, generating a public key binding fingerprint PBTF includes:

[0014] Normalize the trust chain information of the quantum-resistant public key used for signing, including its superior certificate, public key source identifier, or registration transparent log item, to obtain a standardized trust chain data structure;

[0015] 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;

[0016] Performing digest calculation on the data body to be bound using a preset hash algorithm to obtain fingerprint data;

[0017] The fingerprint data is inserted into the extension field of the JWT header as the public key binding fingerprint PBTF, and is signed with the quantum-resistant signature algorithm together with the header and payload.

[0018] Preferably, the parsing process after receiving the JWT at the verification end includes:

[0019] Parse the received JWT token and separate the header, payload, and signature into three parts according to the dot-separated structure. Perform base64url decoding on the header to obtain a structured JSON data object. Extract the key fields from the header JSON object: the field alg representing the signature algorithm, the field kid representing the public key identifier, and the public key binding fingerprint field pbtf.

[0020] Preferably, pulling the corresponding public key from the preset key publishing endpoint based on the kid field includes: reading the kid field in the JWT header and parsing the corresponding public key unique identifier; searching the local cache for a public key record corresponding to the kid, extracting the public key and continuing with subsequent processing if a hit is found, and proceeding to the next step if a hit is found; initiating a secure connection request to the preset key publishing endpoint to pull the public key information matching the kid, and the connection needs to be verified by the TLS certificate chain; performing a structural check on the pulled public key information to confirm that it meets the expected quantum-resistant key format requirements.

[0021] Preferably, the steps of calculating the Trust Path Authentication Level TPAL include:

[0022] Obtain the public key record that matches the key from the key publishing endpoint and parse the trust chain information, which includes the signature of the superior certificate, the key registration authority identifier, and the key transparent log item;

[0023] 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 transparent log or blockchain registration record;

[0024] A weighted score is assigned to the trust factors that pass verification, including 40 points for successful certificate signature verification, 30 points for key whitelist hits, and 30 points for the existence of transparent logs, with a total score of 100 points.

[0025] The obtained weighted total score is used as the trust path authentication level TPAL of the public key.

[0026] Preferably, the calculation steps of the public key behavior consistency score KBCS include:

[0027] Query the usage records of the public key associated with the current kid in the system over the past period of time, extract the issuance frequency, issuance time distribution, issuance purpose domain name, and historical change count;

[0028] A behavioral benchmark model is set for each behavioral parameter, including an average daily issuance of no more than 50 times as normal, no more than 2 domain names for use as stable, and a kid that does not change within a month for higher consistency;

[0029] Compare the behavioral parameters of the current public key with the baseline model and assign a score based on the degree of deviation, including a 30-point deduction for exceeding the frequency limit, a 20-point deduction for excessive diversity of use, and a 50-point deduction for frequent changes;

[0030] The deduction results are summed and negated by 100 to obtain the behavior consistency score KBCS of the current public key.

[0031] Preferably, calculating the PBTF* value and comparing it with the PBTF embedded in the JWT for consistency includes:

[0032] 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 build a structured trust chain data body;

[0033] Sequentially concatenate the structured trust chain data body and the JWT payload content to construct a binding data body;

[0034] The constructed binding data body is hashed using a preset digest function to generate a PBTF* fingerprint value. The calculation process is as follows: the concatenated data body is input into the digest function to obtain a fixed-length digest value as PBTF*;

[0035] The calculated PBTF* value is compared with the original PBTF field value embedded in the JWT Header for consistency. If they are consistent, it is confirmed that the JWT has not been tampered with and the source of the public key used is trustworthy. If they are inconsistent, the current signature verification process is marked as a high-risk state and the exception response mechanism is triggered.

[0036] Preferably, δ is a Boolean penalty function, if the binding fingerprints are consistent, the penalty term is 0; if they are inconsistent, the penalty term is set to a fixed value, R is between 0 and 100.

[0037] Preferably, the trust level and processing strategy are determined according to the interval that the R value falls into: if R is less than or equal to 30, it indicates security and trustworthiness; R between 30 and 50 indicates medium risk; R greater than 50 indicates high risk and verification is rejected.

[0038] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0039] 1. This invention introduces a public key binding fingerprint mechanism to strongly bind the JWT's service payload to the public key trust chain used for signatures. This addresses the existing issue of the verification end being unable to verify the authenticity of the public key, making it easy for forged keys to bypass signature verification. Furthermore, by recalculating the PBTF* on the verification end and comparing it with the original PBTF for consistency, this effectively enhances the structural integrity and tamper resistance of the signature verification process, making it particularly suitable for complex trust environments supporting quantum-resistant signature algorithms.

[0040] 2. This paper proposes a multi-dimensional trust assessment mechanism, constructing a comprehensive risk scoring model that combines TPAL (Trust Path Authentication Level), KBCS (Behavioral Consistency Score), and PBTF comparison results. This model supports dynamic risk assessment for each JWT request and implements differentiated security policies based on the scoring results. This enables a leap from static verification of "signature approval" to a structured decision-making process of "whether the entire system is trustworthy," significantly improving the system's defense capabilities against quantum computing threats and trust source contamination attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments described in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0042] Figure 1 This is a mind map of the method of the present invention. DETAILED DESCRIPTION

[0043] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0044] For examples, see Figure 1 As shown, the method for enhancing the quantum security of the open authorization protocol described in this embodiment includes:

[0045] Obtain the public key of the quantum-resistant encryption algorithm used for signing 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;

[0046] Embed the PBTF as part of the JWT header and sign it together. After receiving the JWT, the verification end parses the JWT and extracts the signature algorithm field, public key identifier field kid, and PBTF field in its header.

[0047] Pull the corresponding public key from the preset key publishing endpoint based on the kid field; perform a multi-dimensional trust assessment on the pulled public key, including calculating the public key trust path authentication level (TPAL) and the public key behavior consistency score (KBCS);

[0048] Based on the extracted JWT payload content and the pulled public key trust chain, the PBTF* value is recalculated and compared with the PBTF embedded in the JWT for consistency;

[0049] The trust path authentication level TPAL, the behavior consistency score KBCS and the public key binding fingerprint consistency check result are taken as input to build a comprehensive risk scoring model and calculate the risk value R comprehensively. The expression is: ;in, is the weighting coefficient, δ is the Boolean penalty function;

[0050] Based on the risk value R, it is determined whether the public key used by the current JWT is credible, and a decision is made according to a preset threshold.

[0051] In the process of the authorization server generating JWT, the PBTF generation and embedding method provided by the present invention includes the following four steps:

[0052] First, before generating the JWT signature, the authorization server obtains the public key used for signing and its corresponding trust chain information. The trust chain may include but is not limited to:

[0053] Digital certificate of the superior issuer;

[0054] Key registration records of the organization to which they belong;

[0055] Public key transparency logging (e.g. Key Transparency Log);

[0056] A unique identifier for the source of the public key, such as the URL endpoint of a JWK Set.

[0057] To facilitate subsequent digest calculation and consistency verification, the above information needs to be uniformly formatted into a standardized trust chain data structure. For example, this can be represented using a JSON object or structured binary encoding, including fields such as the hash value, issuance time, issuing authority, and JWK source address of each certificate level, arranged in a fixed order to ensure consistency across systems.

[0058] After completing the JWT header and payload, the present invention combines the trust chain data structure with the JWT content to construct a binding data body for generating a PBTF. The binding data body can adopt the following structure:

[0059] Standardized sequence of trust chain structures;

[0060] JWT header fields;

[0061] The payload field of the JWT;

[0062] Optional system environment parameters (such as issuer ID, issuance timestamp, etc.).

[0063] Through orderly combination, the binding data body makes the generation of PBTF 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.

[0064] The bound data is hashed using a collision-resistant and quantum-resistant digest algorithm to generate a unique and irreversible PBTF value. This digest algorithm may include SHA-512, BLAKE3, or a quantum-resistant digest algorithm compatible with lattice cryptography.

[0065] The PBTF generation process can be described as: "Using the selected hash function, a digest is calculated on the combined data of the trust chain data, the JWT header, and the payload to obtain a fixed-length digest result, which serves as the public key binding fingerprint PBTF."

[0066] The PBTF value should have the following characteristics:

[0067] A slight change in the input will result in a completely different output (anti-forgery); the public key or original data cannot be deduced from the PBTF (anti-reversal); the result has a fixed length (suitable for embedding in the JWT header); it can be generated consistently across environments (easy to recalculate on the verification side).

[0068] After generating the PBTF value, it is embedded as a new field in the JWT header. The authorization server then signs the header and payload using a quantum-resistant signature algorithm (such as Dilithium or Falcon), ensuring that the PBTF field, along with the JWT content, is protected from tampering. In actual system deployments, PBTF can also be encoded using base64URL with the compact JWT encoding method to ensure compatibility.

[0069] JWT is a token represented by a three-part structure. After receiving the JWT, the validator first splits the entire JWT string at the period to obtain the three parts. It then performs base64url decoding on the header to obtain the header data object in JSON format.

[0070] From the header data, the validator extracts the following fields and processes them separately:

[0071] Signature algorithm field alg: Used to indicate the quantum-resistant encryption algorithm used for the signature, such as "DILITHIUM2" and "FALCON512". This field is used to subsequently select an appropriate signature verifier.

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

[0073] Public key binding fingerprint field pbtf: This field is a key extension field proposed in this invention, which represents the hash fingerprint value after binding the signature public key trust chain with the JWT content. It is an auxiliary credential to ensure that the JWT has not been replaced and the source of the public key is trustworthy.

[0074] In order to prevent an attacker from forging a pbtf field with similar structure but illegal content, after extracting the pbtf field, the present invention should also perform semantic and structural legitimacy verification on the value of the field, including but not limited to:

[0075] Check whether the field exists; whether the field length is consistent with the expected digest algorithm output length (for example, SHA-512 output is 512 bits, or 64 bytes, which is approximately 86 characters after base64url encoding);

[0076] Whether it consists of valid characters to avoid the injection of malicious scripts or binary residues;

[0077] Is it compatible with the signature algorithm declared in the JWT? For example, if the JWT is signed with the "DILITHIUM2" algorithm, a quantum-resistant digest function (such as SHA-512 or BLAKE3) should be used to generate the pbtf.

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

[0079] After receiving the JWT, the verification end must first parse the JWT header. The header is a base64url-encoded JSON data structure containing fields such as alg, typ, and kid.

[0080] 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 JSON Web Key or a sub-segment of a URI identifier.

[0081] The pull process includes the following steps:

[0082] Local cache match: The system first searches the local cache for a public key record that matches the kid; if a match is found, the public key is directly extracted for subsequent verification, thereby improving response speed and offline availability.

[0083] Pulling the remote key endpoint: If the local cache does not hit, the system will construct an HTTPS request and initiate a connection request to the preset key publishing endpoint, for example:

[0084] This request must go through the TLS secure channel and verify that the server's certificate chain is trusted to prevent man-in-the-middle attacks or forged server responses.

[0085] Structural verification and filtering: The pulled JWK data is a collection of public key JSON objects. The system needs to perform structural verification on the items that match kid to confirm whether they conform to the currently supported quantum-resistant key format specifications, such as whether they have key fields such as kty, alg, x, crv, and whether they use supported quantum-resistant algorithms (such as Dilithium and Falcon).

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

[0087] Once a public key is successfully retrieved, a structured assessment of its trustworthiness is required. The Trust Path Assurance Level (TPAL) measures the integrity of the public key's authentication within the trust chain, with a score ranging from 0 to 100, where higher scores indicate greater trustworthiness.

[0088] The calculation steps are as follows:

[0089] Trust factor extraction: Analyze the trust chain information carried by the public key. The trust chain may include:

[0090] Digital certificate of the superior issuer (certificate signature);

[0091] The unique identifier of the key registration authority (e.g., DID, CA ID);

[0092] Entries in the Key Transparency log;

[0093] Key declaration records in a blockchain or trusted audit system.

[0094] Factor verification logic:

[0095] The certificate signature is verified by the trusted root certificate chain and is marked as "valid";

[0096] The registration authority identifier exists in the system's preset whitelist, which is recorded as a "hit";

[0097] If the corresponding hash record exists in the key transparent log and has not been revoked, it is recorded as "existing".

[0098] Weighted scoring rules:

[0099] The certificate signature verification is successful, and the value is 40 points;

[0100] If the registration mark is hit, 30 points will be assigned;

[0101] The key transparency log exists and is worth 30 points.

[0102] TPAL calculation results:

[0103] The system sums the scores of the above factors to produce a Trust Path Authentication Level (TPAL) between 0 and 100. For example, if the certificate verification is successful and the transparent log exists, but the registration identifier is not matched, the TPAL score is 70.

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

[0105] The scoring steps are as follows:

[0106] Behavioral parameter extraction:

[0107] Frequency of issuance (e.g., number of issuances in the past 7 days);

[0108] Issuance time distribution (whether it is concentrated in a certain time period);

[0109] Domain name used (the number of service domain names issued by this public key);

[0110] Number of historical changes (whether the kid has frequently changed the public key in recent times);

[0111] Baseline behavior model settings:

[0112] A daily issuance of no more than 50 times is considered “normal”;

[0113] Domain names with no more than 2 purposes are considered "stable";

[0114] If the kid is not changed within one month, it is considered “high consistency”.

[0115] Deviation from the scoring mechanism:

[0116] The system compares the current actual behavior with the baseline model:

[0117] If the number of issuances exceeds the upper limit, 30 points will be deducted;

[0118] If the number of domain names used exceeds the threshold, 20 points will be deducted;

[0119] If frequent changes occur, 50 points will be deducted.

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

[0121] After receiving the JWT on the verification end, the system performs the PBTF* calculation and comparison process, which mainly includes the following steps:

[0122] The system first parses the JWT structure and divides it into three parts: Header, Payload, and Signature. Specifically:

[0123] Perform base64url decoding on the Header and Payload respectively;

[0124] Extract the pbtf field from the header, which is the public key binding fingerprint embedded by the issuing end;

[0125] Extract JWT's core business data (such as sub, iat, iss, exp, etc.) from Payload;

[0126] Extract the trust chain data from the previously pulled public key record, including but not limited to:

[0127] The certificate chain signed by the superior CA;

[0128] Public key registration source identifier;

[0129] Registration information of the public key in Key Transparency or blockchain.

[0130] The above data constitute the basic dataset required for PBTF* reconstruction.

[0131] To ensure verifiability and cross-platform consistency in PBTF calculation results, the extracted trust chain data and payload content must be combined into a standardized data body. Specific rules include: Fixed order: First, arrange the various fields in a preset order, such as trust chain items first, then payload fields; Standardized format: All field contents are uniformly encoded in JSON or CBOR encoding, and mixing is prohibited; Field delimiters: Use clear delimiters (such as double-quoted field names and colons) to ensure unambiguous structure; Character set restrictions: Uniformly use UTF-8 encoding to avoid discrepancies in summary values ​​due to character set differences.

[0132] For the constructed data body, the system uses the specified digest algorithm to perform hash calculation and generate the PBTF* fingerprint value. The optional digest algorithms include:

[0133] SHA-512 (recommended default algorithm, suitable for most common platforms);

[0134] BLAKE3 (high-performance concurrent scenarios);

[0135] It can be replaced with a quantum-resistant digest algorithm (such as the hash function used in SPHINCS+) to adapt to post-quantum encryption requirements.

[0136] 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 PBTF*.

[0137] The calculation process is expressed in words as follows:

[0138] Using the set hash function, the binding data body constructed in step 2 is used as input, and the fixed-length digest value calculated is called PBTF*, which is used to represent the joint fingerprint of the current JWT content and the trust chain.

[0139] The system compares the PBTF* calculated in the previous step with the pbtf field embedded in the JWT header byte by byte. If the two are identical, the JWT payload content matches the declared public key source and has not been tampered with or the signer has not changed. 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 issuing key; the authorization server has been contaminated or impersonated by the public key publishing endpoint; an attacker has forged the PBTF but failed to reconstruct the true hash structure.

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

[0141] The calculation formula for the total risk score R is as follows (expressed in words):

[0142] Subtract the score of the trust path authentication level TPAL from 100 to obtain the "degree of trust deficiency" 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, where the larger the value, the higher the risk. Specifically expressed as: ; where is the weighting coefficient, δ 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;

[0143] The fingerprint inconsistency penalty term takes values in two cases:

[0144] 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 can be calculated according to factors such as the historical error frequency PBTF difference degree (such as 30 - 70);

[0145] The weight coefficients can be flexibly configured according to the deployment environment. For example: the first weight is set to 0.5; the second weight is set to 0.3; the third weight 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.

[0146] Based on the calculated R value, the system can automatically divide the current verification situation into different trust levels and perform corresponding processing actions:

[0147] Low risk (R ≤ 30): It means that the public key trust chain of this JWT signature is complete, the historical behavior is consistent, and the PBTF verification passes; it can be regarded as a trustworthy request, and the signature verification is normally completed and access to resources is allowed.

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

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

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

[0151] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. 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 program are loaded or executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. 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 data center that contains one or more available media sets. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0152] It should be understood that the term "and / or" herein is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B may represent three situations: A exists alone, A and B exist at the same time, and B exists alone, where A and B may be singular or plural. In addition, the character " / " herein generally indicates that the objects associated with each other are in an "or" relationship, but it may also indicate an "and / or" relationship, which can be understood by referring to the context. A person of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0153] The above is only a specific implementation method of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed in this application, which should be covered by the scope of protection of the present application.

Claims

1. A method for enhancing quantum security of an open licensing protocol, characterized by: include: Obtain the public key of the quantum-resistant encryption algorithm used for signing 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 part of the JWT header and sign it together. After receiving the JWT, the verification end parses the JWT and extracts 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 publishing endpoint; Perform multi-dimensional trust assessment 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, the PBTF* value is recalculated and compared with the PBTF embedded in the JWT for consistency; Construct a risk scoring model and comprehensively calculate the risk value R, which is expressed as: ;in, is the weighting coefficient, δ is the Boolean penalty function; Specifically, it includes: reading and parsing the payload content in the JWT, and extracting the complete trust chain information from the public key record pulled by the verification end, including the upper-level certificate, registration identifier, and key registration path components, to build a structured trust chain data body; Sequentially concatenate the structured trust chain data body and the JWT payload content to construct a binding data body; The constructed binding data body is hashed using a preset digest function to generate a PBTF* fingerprint value. The calculation process is as follows: the concatenated data body is input into the digest function to obtain a fixed-length digest value as PBTF*; The calculated PBTF* value is compared with the original PBTF field value embedded in the JWT Header for consistency. If they are consistent, it is confirmed that the JWT has not been tampered with and the source of the public key used is trustworthy. If they are inconsistent, the current signature verification process is marked as high-risk and the exception response mechanism is triggered; The Boolean penalty function δ specifically means: if the binding fingerprints are consistent, the penalty term is 0; if they are inconsistent, the penalty term is set to a fixed value, R between 0 and 100; Based on the risk value R, it is determined whether the public key used by the current JWT is credible, and a decision is made according to a preset threshold.

2. The method for enhancing quantum security of an open licensing protocol according to claim 1, wherein: Generating 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 transparent log item, 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; Performing digest calculation on the data body to be bound using a preset hash algorithm to obtain fingerprint data; The fingerprint data is inserted into the extension field of the JWT header as the public key binding fingerprint PBTF, and is signed with the quantum-resistant signature algorithm together with the header and payload.

3. The method for enhancing quantum security of an open licensing protocol according to claim 1, wherein: The parsing process after receiving the JWT at the verification end includes: Parse the received JWT token and separate the header, payload, and signature into three parts according to the dot-separated structure. Perform base64url decoding on the header to obtain a structured JSON data object. Extract the key fields from the header JSON object: the field alg representing the signature algorithm, the field kid representing the public key identifier, and the public key binding fingerprint field pbtf.

4. The method for enhancing quantum security of an open licensing protocol according to claim 1, wherein: Pulling the corresponding public key from the preset key publishing endpoint based on the kid field includes: reading the kid field in the JWT header and parsing the corresponding public key unique identifier; searching the local cache for a public key record corresponding to the kid; if a hit is found, extracting the public key and continuing with subsequent processing; if not, proceeding to the next step; initiating a secure connection request to the preset key publishing endpoint to pull the public key information matching the kid, and the connection must be verified by the TLS certificate chain; and performing a structural check on the pulled public key information to confirm that it meets the expected quantum-resistant key format requirements.

5. The method for enhancing quantum security of an open licensing protocol according to claim 4, characterized in that: The steps for calculating the Trust Path Authentication Level TPAL include: Obtain the public key record that matches the key from the key publishing endpoint and parse the trust chain information, which includes the signature of the superior certificate, the key registration authority identifier, and the key transparent log item; 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 transparent log or blockchain registration record; A weighted score is assigned to the trust factors that pass verification, including 40 points for successful certificate signature verification, 30 points for key whitelist hits, and 30 points for the existence of transparent logs, with a total score of 100 points. The obtained weighted total score is used as the trust path authentication level TPAL of the public key.

6. The method for enhancing quantum security of an open licensing 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 the past period of time, extract the issuance frequency, issuance time distribution, issuance purpose domain name, and historical change count; A behavioral benchmark model is set for each behavioral parameter, including an average daily issuance of no more than 50 times as normal, no more than 2 domain names for use as stable, and a kid that does not change within a month for higher consistency; Compare the behavioral parameters of the current public key with the baseline model and assign a score based on the degree of deviation, including a 30-point deduction for exceeding the frequency limit, a 20-point deduction for excessive diversity of use, and a 50-point deduction for frequent changes; The deduction results are summed and negated by 100 to obtain the behavior consistency score KBCS of the current public key.

7. The method for enhancing quantum security of an open licensing protocol according to claim 1, wherein: The trust level and processing strategy are determined based on the range that the R value falls into: if R is less than or equal to 30, it indicates security and trustworthiness; R between 30 and 50 indicates medium risk; R greater than 50 indicates high risk and verification is rejected.

Images