Server security authentication system based on block chain trusted computing

Abstract

The invention relates to the field of network and information security, and discloses a server security authentication system based on block chain trusted computing. Comprising a block chain network, an intelligent contract module, an authentication service module, a verification node and a to-be-authenticated server. The intelligent contract module records a registration index, a certification public key, a policy version number, a baseline commitment value and a revocation state. The authentication service module generates a challenge parameter and a challenge value based on the block height and the block hash digest. The trusted agent module collects a measurement abstract and forms a certification packet, and the trusted root module derives a staging certification key in a protected environment and signs the certification packet. And the verification node reads the data on the chain to complete signature verification, challenge value re-calculation, window verification and compliance proof verification, and generates an authentication bill containing an effective height range for resource access judgment after passing the verification.

Description

Technical Field

[0001] This invention relates to the field of network and information security, and specifically to a server security authentication system based on blockchain trusted computing. Background Technology

[0002] With the widespread adoption of cloud-native technologies, microservices, and edge computing, business systems are typically hosted on multiple servers and various runtime environments, with resource access primarily taking the form of API calls, service discovery, and dynamic scaling. If a server is impersonated, its image replaced, critical binary data tampered with, or its configuration abnormally modified, attackers can take over service processes without altering the business entry point, leading to data breaches, privilege abuse, and supply chain-style lateral movement. Therefore, reliably authenticating server identity and operating environment before resource access, and continuously restricting access validity and revocation status after authentication, has become a fundamental capability for zero-trust architecture, compliance auditing, and the deployment of critical business applications.

[0003] Existing server authentication typically employs a centralized trust model, with identity verification provided by a certificate system and authentication platform, and remote proof output via trusted hardware such as TPM or TEE. Specifically, on the server side to be authenticated, an agent program collects startup metrics and operational attitude metrics, generates a metric digest, signs it, and reports it. The authentication platform maintains a trusted baseline library and policy versions, receives proof, performs signature verification, comparison, and policy determination, and then issues tokens or tickets to clients or gateways for subsequent access control. To adapt to deployments across multiple services, clusters, and environments, information such as baseline version updates, registration indexes and public key bindings, revocation, and blacklist synchronization is typically distributed through the platform database, configuration center, or message channels. In scenarios with multiple verification nodes or cross-organizational collaboration, state consistency may also be maintained through reconciliation, scheduled synchronization, or master-slave replication.

[0004] The critical states of the aforementioned schemes heavily rely on centralized platforms and synchronization mechanisms. Delays and inconsistencies can easily occur between different verification sides in areas such as registration index and public key mapping, baseline version and hash algorithm selection, and revocation and blacklist status. This can lead to different authentication conclusions from the same server on different nodes, making it difficult to form a unified and traceable audit chain. Secondly, remote proofs still face risks of replay and cross-period reuse in many scenarios. If challenge parameters lack binding with uncontrollable temporal states, proof packets may be reused outside their validity period. Thirdly, maintaining trusted baselines is costly and carries a high risk of leakage. If baseline details are exposed during distribution or storage, it expands the attack surface and provides clues for targeted bypasses. For these reasons, there is an urgent need for a server security authentication technology that can provide a consistent state source in a multi-node environment, has clear time constraints, and balances baseline privacy and verifiability. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a server security authentication system based on blockchain trusted computing to solve the technical problems existing in the prior art.

[0006] The above-mentioned technical objective of the present invention is achieved through the following technical solution: A server security authentication system based on blockchain trusted computing includes: Blockchain network, smart contract module, authentication service module, verification node, and server to be authenticated; The server to be authenticated sets up a trusted proxy module and connects to a trusted root module. The trusted proxy module is used to collect the metric digest of the server to be authenticated and generate a proof package, and submit the proof package to the trusted root module. The trusted root module is a trusted platform module or a trusted execution environment. The trusted root module generates a phased proof key using the registration index, block hash digest and block height window as inputs through a key derivation function in a protected environment, and calculates the signature value of the proof package based on the phased proof key. The smart contract module is deployed on the blockchain network and includes a registration contract, a strategy contract, and a revocation contract. The registration contract is used to record the correspondence between the registration index and the proof public key on the chain. The strategy contract is used to record the correspondence between the strategy version number and the baseline commitment value on the chain. The baseline commitment value is the Merkle root. The revocation contract is used to record the revocation status of the registration index on the chain. The authentication service module obtains the block height and corresponding block hash digest, and generates challenge parameters based on client random numbers, block height, block hash digest, policy version number, and resource identifier. These challenge parameters include the starting height and window length of the block height window, and are sent to the trusted proxy module. The authentication service module concatenates the challenge parameters according to preset encoding rules, performs a hash operation to obtain a challenge value, and sends the challenge value to the trusted proxy module. The proof package contains the challenge value. The verification node recalculates the challenge value based on the challenge parameters in the proof package and performs consistency verification. The proof package includes a registration index, policy version number, block height, resource identifier, metric digest, and challenge parameters, and includes a signature value calculated by the trusted root module, as well as a compliance proof that characterizes the consistency between the metric digest and the baseline commitment value set. The verification node is used to read the baseline commitment value from the blockchain network based on the policy version number, read the proof public key and revocation status, verify the proof package signature, recalculate the challenge value and perform consistency verification, verify that the block height is within the block height window and verify that the compliance proof matches the baseline commitment value; when the verification passes and the revocation status is not revoked, an authentication ticket is generated and the ticket index or its digest, policy version number and authentication conclusion digest are written to the blockchain network. The authentication ticket includes a ticket index, resource identifier, policy version number, and valid height range of the ticket. The authentication service module returns the authentication ticket to the client. When the client accesses the resource, it carries the authentication ticket. The verification node determines whether the access request is approved based on the ticket index, revocation status, and valid height range of the ticket, and rejects the access request if it fails.

[0007] Preferably, the trusted root module is a trusted platform module, which includes a key storage area, a key derivation unit, and a signature unit; The key storage area pre-stores the master key. The trusted proxy module submits the registration index, block hash digest, starting height of the block height window, and length of the block height window to the trusted platform module through a local call interface. In the key derivation unit, the trusted platform module performs key derivation operations on the registration index, block hash digest, starting height of the block height window, and length of the block height window using the master key to obtain the phased proof key. In the signature unit, the module calculates the signature value of the proof package based on the phased proof key and returns it to the trusted proxy module.

[0008] Preferably, the trusted root module is a trusted execution environment, which includes a protected execution area and a key storage area; The trusted proxy module writes the registration index, block hash digest, starting height of the block height window, and length of the block height window into the protected execution area. The trusted execution environment performs key derivation operations in the protected execution area to obtain the phased proof key and writes the phased proof key into the key storage area. The trusted proxy module writes the proof package into the protected execution area, and the trusted execution environment calculates the signature value of the proof package based on the phased proof key within the protected execution area and returns it to the trusted proxy module.

[0009] Preferably, the registration contract maintains a registration record table on the blockchain network, and the registration records in the registration record table include a registration index, a proof public key, a server identifier, and a registration status; The revocation contract maintains a revocation record table on the blockchain network. The revocation record table includes a registration index, revocation status, and revocation block height. Before verifying the proof package, the verification node reads the proof public key from the registration contract based on the registration index, and reads the revocation status and revocation block height from the revocation contract based on the registration index.

[0010] Preferably, the strategy contract maintains a strategy record table on the blockchain network, and the strategy records in the strategy record table include a strategy version number, a baseline commitment value, a hash algorithm identifier, and a leaf node encoding rule identifier. The baseline commitment value is the Merkle root obtained by generating a leaf node digest of the trusted baseline set according to the leaf node encoding rules and constructing a Merkle tree according to the hash algorithm. The verification node reads the baseline commitment value, hash algorithm identifier, and leaf node encoding rule identifier from the strategy contract based on the strategy version number.

[0011] Preferably, the authentication service module reads the current block height and the corresponding block hash digest from the blockchain network, determines the current block height as the starting height of the block height window, and determines the preset window length as the block height window length; The challenge parameters include client random number, block hash digest, starting height of block height window, length of block height window, policy version number, and resource identifier; The authentication service module concatenates the challenge parameters according to a preset encoding rule, performs a hash operation to obtain the challenge value, and sends the challenge parameters and the challenge value to the trusted proxy module.

[0012] Preferably, the metric digest collected by the trusted proxy module consists of a startup metric digest and a running attitude metric digest; The boot metric digest is obtained by concatenating the digest value of the operating system kernel image file and the digest value of the bootloader file according to a preset encoding rule and then performing a hash operation. The runtime attitude metric digest is obtained by concatenating the digest value of the container image identifier and the digest value of the critical service executable file according to a preset encoding rule and then performing a hash operation. The metric digest is the output value obtained by performing a hash operation on the concatenation of the startup metric digest and the running attitude metric digest according to a preset encoding rule.

[0013] Preferably, the key derivation function in the trusted root module takes the registration index, block hash digest, starting height of the block height window, and length of the block height window as input, and outputs the phased proof key with the root key stored in the trusted root module as the derived root key; The trusted proxy module writes the registration index, policy version number, block height, resource identifier, metric digest, challenge parameters, and challenge value into the proof package, and submits the proof package to the trusted root module to calculate the signature value and then encapsulates it into the proof package.

[0014] Preferably, the compliance proof is a Merkle path proof, which includes a leaf node digest, a path node digest sequence, and a node direction sequence. The leaf node digest is obtained by concatenating the metric digest and the policy version number according to the encoding rule corresponding to the leaf node encoding rule identifier and then performing a hash operation. The verification node calculates the recalculated root value layer by layer based on the path node summary sequence and the node direction sequence, and performs consistency verification between the recalculated root value and the baseline commitment value.

[0015] Preferably, the verification node generates an authentication ticket when the proof package passes verification and the revocation status is not revoked. The authentication ticket includes a ticket index, a registration index, a resource identifier, a policy version number, a valid ticket height range, and a ticket signature value. The valid ticket height range includes a ticket start height and a ticket end height. The ticket start height is the block height when the authentication ticket is generated, and the ticket end height is the sum of the ticket start height and the preset ticket valid window length. The verification node concatenates the ticket index, registration index, resource identifier, policy version number, and ticket valid height range according to a preset encoding rule, performs a hash operation to obtain a ticket digest, and calculates the ticket signature value based on the ticket private key. The verification node writes the ticket index or its summary, the registration index, the policy version number, and the authentication conclusion summary into the blockchain network. When a client accesses a resource, it carries an authentication ticket. The verification node determines whether the access request passes based on the ticket signature value, the consistency between the resource identifier in the access request and the resource identifier in the authentication ticket, whether the current block height is within the valid height range of the ticket, and the revocation status of the contract read.

[0016] In summary, the present invention has the following main beneficial effects: This invention deploys registration contracts, policy contracts, and revocation contracts in a blockchain network, solidifying the registration index and proof public key, policy version number and baseline commitment value, and revocation status into traceable on-chain states. Verification nodes read and verify these on-chain states in real time during authentication and access determination, achieving the effect of unifying server identity credentials, trusted baselines, and revocation control into a single root of trust. This avoids the trust drift problem caused by asynchronous credential distribution and revocation in traditional centralized authentication, and improves the consistency and auditability of authentication conclusions in cross-domain, multi-verification-node scenarios.

[0017] This invention generates challenge parameters and calculates challenge values ​​based on client-side random numbers, block height and corresponding block hash digests, policy version numbers and resource identifiers through an authentication service module. It also incorporates the block height window as a component of the challenge parameters and recalculates the challenge value and verifies the validity of the window on the verification node side. This achieves the effect of binding authentication requests with on-chain time-series states and client-side random sources, thereby reducing the risk of replay and cross-period reuse after the proof packet is intercepted, and giving the authentication conclusion a clear time boundary to facilitate the unified execution of access control policies.

[0018] This invention derives phased proof keys from the registration index, block hash digest, and block height window within the protected environment of the trusted root module, and calculates the signature value of the proof package using the server to be authenticated. At the same time, it uses Merkle path proof to characterize the consistency relationship between the metric digest and the corresponding set of baseline commitment values ​​through compliance proof. This achieves the effect of verifying metric compliance without exposing the entire set of trusted baselines, thereby reducing the attack surface caused by the leakage of baseline details. Furthermore, it achieves unified verification on the verification node side by matching the recalculated root value with the on-chain baseline commitment value, thereby improving the authentication chain's resistance to tampering and forgery. Attached Figure Description

[0019] Figure 1 This is a system flowchart of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Example 1 refer to Figure 1 A server security authentication system based on blockchain trusted computing includes: Blockchain network, smart contract module, authentication service module, verification node, and server to be authenticated; The server to be authenticated sets up a trusted proxy module and connects to a trusted root module. The trusted proxy module is used to collect the metric digest of the server to be authenticated and generate a proof package, and submit the proof package to the trusted root module. The trusted root module is a trusted platform module or a trusted execution environment. The trusted root module generates a phased proof key using the registration index, block hash digest and block height window as inputs through a key derivation function in a protected environment, and calculates the signature value of the proof package based on the phased proof key. The smart contract module is deployed on the blockchain network and includes a registration contract, a strategy contract, and a revocation contract. The registration contract is used to record the correspondence between the registration index and the proof public key on the chain. The strategy contract is used to record the correspondence between the strategy version number and the baseline commitment value on the chain. The baseline commitment value is the Merkle root. The revocation contract is used to record the revocation status of the registration index on the chain. The authentication service module obtains the block height and corresponding block hash digest, and generates challenge parameters based on client random numbers, block height, block hash digest, policy version number, and resource identifier. These challenge parameters include the starting height and window length of the block height window, and are sent to the trusted proxy module. The authentication service module concatenates the challenge parameters according to preset encoding rules, performs a hash operation to obtain a challenge value, and sends the challenge value to the trusted proxy module. The proof package contains the challenge value. The verification node recalculates the challenge value based on the challenge parameters in the proof package and performs consistency verification. The proof package includes a registration index, policy version number, block height, resource identifier, metric digest, and challenge parameters, and includes a signature value calculated by the trusted root module, as well as a compliance proof that characterizes the consistency between the metric digest and the baseline commitment value set. The verification node is used to read the baseline commitment value from the blockchain network based on the policy version number, read the proof public key and revocation status, verify the proof package signature, recalculate the challenge value and perform consistency verification, verify that the block height is within the block height window and verify that the compliance proof matches the baseline commitment value; when the verification passes and the revocation status is not revoked, an authentication ticket is generated and the ticket index or its digest, policy version number and authentication conclusion digest are written to the blockchain network. The authentication ticket includes a ticket index, resource identifier, policy version number, and valid height range of the ticket. The authentication service module returns the authentication ticket to the client. When the client accesses the resource, it carries the authentication ticket. The verification node determines whether the access request is approved based on the ticket index, revocation status, and valid height range of the ticket, and rejects the access request if it fails.

[0022] The server to be authenticated is configured with a trusted proxy module and connected to a trusted root module. The trusted root module is a trusted platform module or a trusted execution environment, used to derive phased proof keys and calculate signature values ​​for proof packages within a protected environment. The authentication service module interacts with the client and generates challenge parameters and challenge values, which are then sent to the trusted proxy module. The verification node reads the baseline commitment value, proof public key, and revocation status from the blockchain network, performs signature verification, challenge value recalculation consistency verification, block height window verification, and compliance proof verification on the proof package, and generates an authentication ticket and writes it to the chain upon successful verification. Simultaneously, when a client accesses the server, the authentication ticket is evaluated, and unsuccessful access requests are rejected.

[0023] To eliminate ambiguity in responsibilities, this embodiment stipulates that: the trusted proxy module is located in the normal execution environment and is used to collect metric digests, organize proof package fields, receive challenge parameters and challenge values, and initiate controlled calls to the trusted root module; the trusted root module is located in the protected environment and completes the phased proof key derivation operation and proof package signature operation, and the phased proof key does not leave the protected environment; the verification node is responsible for on-chain reading and verification loop, and is responsible for authentication ticket generation and ticket signing.

[0024] The registration contract maintains a registration record table on the blockchain network, and the registration record includes a registration index. Proof of public key Server Identifier and registration status The registration status can be either registered or unregistered. The registration contract is used to record the correspondence between the registration index and the proof public key. The registration transaction writing rule is: when the transaction carries... , , Furthermore, upon successful contract verification, the registration record is written or updated, and the registration status is set to registered.

[0025] The revocation contract maintains a revocation record table on the blockchain network, and the revocation record includes a registration index. Cancellation status and the height of the undo block The revocation status can be either "not revoked" or "revoked". The revocation contract is used to record the revocation status of the registered index on-chain. The rule for writing a revoked transaction is: when a transaction carries... Furthermore, during contract verification, the revocation status is set to revoked and written to the revocation block height. .

[0026] The strategy contract maintains a strategy record table on the blockchain network, and the strategy record includes the strategy version number. Baseline commitment value Hash algorithm identifier and leaf node encoding rule identifier The baseline commitment value is the Merkle root, used to commit to a set of trusted baselines. The policy release transaction write rule is: when a transaction carries... , , , Furthermore, upon successful contract verification, a strategy record is written to the policy log table. Verification nodes are based on... Read the above fields and determine the verification algorithm and encoding rules accordingly.

[0027] The public key for proving the registration contract record is This is used to verify the signature of the proof packet. The root key is stored internally within the trusted root module. Used to derive phased proof keys ,and Without leaving the protected environment. This is to enable the verification node to read... After verification, this example uses a "deterministically derived phased proof key pair" mechanism: Phased proof key Its corresponding signature verification public key Determined by the same derived context, the verification node is based on the on-chain Calculated with derived context and use Verify the signature value of the proof packet. This calculation is a pre-verification processing step, used to implement the execution path of "reading the proof public key and verifying the proof packet signature" in the claims. Derived Context The definition is given in Part Nine of this embodiment. The verification node calculates the public key for this verification session, satisfying the following determining relationship: ; in For the public key derivation operation to match the signature algorithm, the input is the registered contract record. With derived context The output is the public key for this signature verification. .

[0028] The symbols have the following meanings: To register the proof of public key, To derive context, This is the public key for this verification.

[0029] The verification node generates the authentication ticket and signs the ticket digest; the verification node holds the ticket's private key. The corresponding public key for the ticket is To avoid unclear sources of the public key for the invoice, this embodiment uses one of the following two implementations for obtaining and binding the public key for the invoice, and the selected rule remains consistent during system deployment: A: Pre-configured during verification node deployment And write it into the verification node configuration item, the configuration item will identify the verification node. and When binding and verifying a document, the node reads the document from this configuration item. .

[0030] Achieve B: With verification node identifier The system configuration record is written into the blockchain network, and the verification node reads the on-chain data before verifying the signed ticket. And verify local Once the summary matches, the signature verification will be performed.

[0031] Any of the above implementations makes the verification of the document required. It has a definite source and binding relationship.

[0032] This embodiment defines the encoding function. The splicing symbol is The hash function is The signature function is The signature verification function is The message authentication code is .in The specific algorithm is recorded by the strategy contract. The specified verifier node reads from the chain. For compliance, the coding conventions are as follows, all of which are fixed rules: 1. Block height, window length, and ticket height are encoded using 8-byte unsigned big-endian integers.

[0033] 2. The strategy version number uses a 4-byte unsigned integer big-endian encoding.

[0034] 3. The registration index uses a 16-byte fixed-length encoding.

[0035] 4. The client-side random number generator uses a 16-byte fixed-length encoding.

[0036] 5. The resource identifier uses a length prefix encoding, which is a 2-byte unsigned big-endian integer followed by the resource identifier byte sequence.

[0037] 6. Block hash digest Use its original byte sequence.

[0038] 7. The compliance certificate uses a length prefix encoding, which is a 4-byte unsigned big-endian integer followed by the byte sequence of the compliance certificate content.

[0039] To ensure consistency in recalculation, this embodiment further solidifies the three key concatenation orders as follows: The concatenation order of the challenge parameter fields is fixed as follows: Client random number Block hash digest Window start height Window length Strategy version number Resource Identifier The challenge parameters are denoted as... Its byte string is: ; The order of fields to be signed in the proof package is fixed as follows: registration index Strategy version number Block height Resource Identifier Measure summary Challenge parameters Challenge Value Compliance Certificate The signature value field of the proof packet is not included in this concatenation; it is returned by the root of trust module and written into the proof packet. The byte string to be signed is denoted as... Its byte string is: ; in and Encoding the original byte sequence for a fixed-length digest, the length of which is determined by... Confirmed. The order of concatenating the bill summary field is fixed as follows: bill index. Registration Index Resource Identifier Strategy version number Starting height of the bill , End height of bill The ticket input byte string is denoted as... Its byte string is: ; The authentication service module reads the current block height and the corresponding block hash digest from the blockchain network. The current block height is denoted as... The corresponding block hash digest is denoted as The authentication service module determines the starting height of the block height window as follows: Set the preset window length as The authentication service module receives random numbers from the client. Strategy version number With resource identifier Challenge parameters are generated according to the field order in Part IV of this embodiment. The authentication service module calculates the challenge value. : ; The authentication service module will challenge parameters With challenge value Send to the trusted proxy module.

[0040] The trusted proxy module collects metric digests, which consist of a startup metric digest and a runtime attitude metric digest. The byte sequence of the operating system kernel image file is as follows: The byte sequence of the bootloader file is The normalized byte sequence for container image identifiers is: The byte sequence of the critical service executable file is as follows: The abstract is calculated as follows: ; ; ; ; ; ; ; in To initiate metric summarization, Summary of operational attitudes This is a summary of metrics.

[0041] Baseline commitment value recorded in the strategy contract This is the Merkle root of the trusted baseline set. The trusted baseline set consists of several baseline entries, each corresponding to a permitted metric summary value. The leaf node encoding function is... Specify, denoted as The leaf node summary is as follows: ; The parent node's summary is: ; The baseline commitment value is obtained through bottom-up iteration. .

[0042] The trusted proxy module is based on this metric summary With strategy version number Compute leaf node summary: ; The compliance proof is a Merkle path proof, containing leaf node digests. Path node summary sequence With node direction sequence ,in This indicates that the current node is on the left. This indicates that the current node is on the right. The trusted proxy module encodes this Merkle path proof as... Write it into the proof package.

[0043] The trusted proxy module generates proof package fields, including the registration index. Strategy version number Block height Resource Identifier Measure summary Challenge parameters Challenge Value Compliance Certificate and signature value field The byte string to be signed It is obtained by encoding and splicing the fields in the order of the fields solidified in Part 4 of this embodiment.

[0044] The Trusted Root module, within a protected environment, takes the registration index, block hash digest, and block height window as input, and generates a phased proof key via a key derivation function. The derivation context is: ; The root key is stored internally in the trusted root module. The derived intermediate value is: ; Purpose field label is The key for phased proof is: ; in This is a 4-byte unsigned big-endian integer counter.

[0045] When the trusted root module is a trusted platform module, the trusted platform module includes a key storage area, a key derivation unit, and a signature unit. The key storage area pre-stores the master key, which serves as the root key. The trusted proxy module submits data via a local API call. , , , The trusted platform module generates the key derivation unit along with the digest to be signed. and based on the signature unit Calculate the signature value and return it.

[0046] When the trusted root module is a trusted execution environment, the trusted execution environment includes a protected execution area and a key storage area. The trusted proxy module will... , , , The data is written into the protected execution region, and the trusted execution environment performs derivation operations within the protected execution region to obtain the desired result. The data is then sealed and written to the key storage area. The trusted proxy module writes the data to be signed into the protected execution area, and the trusted execution environment operates within the protected execution area based on... Calculate the signature value and return it.

[0047] The digest to be signed in the proof package is: ; The signature value is: ; The root of trust module will sign the value Return to the trusted proxy module, the trusted proxy module will Write the signature value field of the proof package to form the final proof package and send it to the verification node.

[0048] After receiving the proof packet, the verification node performs on-chain reading and verification.

[0049] Based on policy version number Read the baseline commitment value from the strategy contract Hash algorithm identifier Leaf node encoding rule identifier .

[0050] Based on the registration index Read the public key from the registration contract. And read the revocation status from the revocation contract. With the height of the revoked block When the cancellation status is "cancelled," the verification process terminates and the generation of a ticket is rejected.

[0051] The verification node is based on the proof package , , , Constructing derived context And calculate the public key for this verification period according to Section 3.1 of this embodiment: ; The verification node performs signature verification on the proof packet signature: ; The verification node recalculates the challenge value based on the challenge parameters within the proof package: ; And verify .

[0052] Verification node reads current block height The check block height is within the block height window: ; The verification node checks that the compliance proof matches the baseline commitment value. Let: ; when hour: ; when hour: ; The final recalculated root value is Verify node validation: ; When the verification is successful, the challenge value matches, the window is valid, the compliance certificate is approved, and the revocation status is "not revoked", the process of generating the authentication ticket begins.

[0053] The verification node generates an authentication ticket when the proof packet passes verification and the revocation status is not revoked. The authentication ticket includes a ticket index. Registration Index Resource Identifier Strategy version number Valid height range of the bill and signature value of the bill The initial height of the ticket is the block height at which the ticket was generated. The end height of the note is: ; in The preset valid window length for the ticket. The verification node verifies the ticket input byte string. Calculate the invoice summary: ; Verification nodes are based on the private key of the ticket. Calculate the signature value of the document: ; The validator node sends the authentication ticket to the authentication service module, which then returns the authentication ticket to the client. The validator node writes the ticket index or its digest, the registration index, the policy version number, and the authentication conclusion digest to the blockchain network. The authentication conclusion digest is: ; When a client accesses a resource, it carries an authentication ticket. The verification node determines whether the access request is approved based on the ticket index, revocation status, and valid ticket height range. This determination includes: ticket signature verification. Resource identifier consistency check, current block height is The system performs a high-level validity check, as well as a check that the cancellation status is not cancelled; if either check fails, the access request is rejected.

[0054] The verification node refuses to generate a ticket or refuses an access request when any of the following conditions occur: the revocation status is revoked, the proof package verification fails, the recalculation challenge value is inconsistent with the proof package challenge value, the current block height is not within the block height window, the compliance proof recalculation root value is inconsistent with the baseline commitment value, the ticket verification fails, the ticket height range is invalid, or the resource identifier is inconsistent.

[0055] This invention uses the block height and block hash digest provided by the blockchain network as on-chain time-series anchors that progress over time and are difficult to be unilaterally controlled in advance. It uses the registration index and proof public key mapping, policy version number and baseline commitment value mapping, and revocation status, which are fixed on the chain by the smart contract module, as trusted state sources. On the server side to be certified, the trusted proxy module collects the metric digest and organizes the proof package. Then, the trusted root module derives the phased proof key based on the registration index, block hash digest, and block height window in a protected environment and calculates the signature value of the proof package, thereby forming a server authentication evidence chain with verifiable source, verifiable timeliness, and verifiable compliance.

[0056] The authentication service module reads the current block height and the corresponding block hash digest, determines the starting height and window length of the block height window, and encodes and concatenates the client random number, block hash digest, block height window, policy version number, and resource identifier according to the preset encoding rules to generate challenge parameters. The challenge parameters are then hashed to obtain the challenge value and sent to the trusted proxy module, thus binding this authentication to the on-chain block state and the client random number, reducing the risk of replay and cross-period reuse.

[0057] After receiving the challenge parameters and challenge value, the trusted proxy module collects the startup metric digest and running attitude metric digest of the server to be certified and calculates the metric digest. It writes the registration index, policy version number, block height, resource identifier, metric digest, challenge parameters and challenge value into the proof package and generates a compliance proof to characterize that the metric digest belongs to the trusted baseline set. The compliance proof uses leaf node encoding rules and hash algorithms consistent with the baseline commitment values ​​recorded in the strategy contract to construct leaf node digests and form Merkle path proofs. This enables the verification node to recalculate the root value and verify its consistency with the baseline commitment value based solely on the path node digest sequence and node direction sequence without exposing the complete set of trusted baselines, thereby completing the measurement compliance verification.

[0058] After receiving the proof package, the verification node reads the baseline commitment value and related algorithm identifier from the chain according to the policy version number, reads the proof public key from the chain according to the registration index and reads the revocation status. First, it determines the revocation status to block the authentication process of the revoked registration index. Then, it performs signature verification on the proof package signature, recalculates the challenge value according to the challenge parameters in the proof package and verifies the consistency of the challenge value in the proof package. At the same time, it verifies that the current block height is within the block height window limited by the challenge parameters. Finally, it performs Merkle recalculation on the compliant proof and verifies the matching of the on-chain baseline commitment value. When all the above verifications pass and the revocation status indicates that the authentication has not been revoked, the verification node generates an authentication ticket and writes the ticket index or its summary, registration index, policy version number and authentication conclusion summary into the blockchain network to achieve on-chain traceability of the authentication results.

[0059] The authentication ticket contains a ticket index, resource identifier, policy version number, and valid height range of the ticket, as well as a ticket signature value. The authentication service module returns the authentication ticket to the client. When the client accesses a resource, it carries the authentication ticket. The verification node performs signature verification on the ticket signature value and verifies that the resource identifier of the access request is consistent with the resource identifier of the ticket, that the current block height is within the valid height range of the ticket, and that the revocation status is not revoked. Based on this, it determines whether the access request is approved. Access requests are rejected when any condition is not met, thereby converting the one-time authentication result into access credentials that can be repeatedly verified within the valid height of the ticket, and immediately blocking subsequent access after the contract is revoked and the revocation status is updated.

[0060] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A server security authentication system based on blockchain trusted computing, characterized in that, The application relates to a blockchain network, an intelligent contract module, an authentication service module, a verification node and a server to be authenticated. The server to be authenticated is provided with a trusted agent module and is connected with a trusted root module, the trusted agent module is used for collecting a measurement digest of the server to be authenticated and generating a proof package, and the proof package is submitted to the trusted root module; the trusted root module is a trusted platform module or a trusted execution environment, the trusted root module generates a staged proof key by a key derivation function in a protected environment and takes a registration index, a block hash digest and a block height window as input, and calculates a signature value of the proof package based on the staged proof key; The intelligent contract module is deployed on the blockchain network and comprises a registration contract, a strategy contract and a revocation contract, the registration contract is used for recording a corresponding relationship between a registration index and a proof public key on a chain, the strategy contract is used for recording a corresponding relationship between a strategy version number and a baseline commitment value on the chain, the baseline commitment value is a Merkle root, and the revocation contract is used for recording a revocation state of the registration index on the chain; The authentication service module is used for obtaining a block height and a corresponding block hash digest, generating a challenge parameter based on a client random number, the block height, the block hash digest, a strategy version number and a resource identifier, sending the challenge parameter to the trusted agent module, performing a hash operation on the challenge parameter after splicing according to a preset coding rule to obtain a challenge value, and sending the challenge value to the trusted agent module; the proof package comprises the challenge value; the verification node recalculates the challenge value according to the challenge parameter in the proof package and performs consistency checking; The proof package comprises a registration index, a strategy version number, a block height, a resource identifier, a measurement digest and a challenge parameter, comprises a signature value calculated by the trusted root module, and comprises a compliance proof for indicating that the measurement digest is consistent with a corresponding set of baseline commitment values; The verification node is used for reading a baseline commitment value from the blockchain network based on a strategy version number, reading a proof public key and a revocation state, verifying a proof package signature, recalculating a challenge value and performing consistency checking, checking whether a block height is in the block height window and checking whether a compliance proof matches the baseline commitment value; when the checking passes and the revocation state is not revoked, an authentication ticket is generated, and a ticket index or a digest thereof, a strategy version number and an authentication conclusion digest are written into the blockchain network; The authentication ticket comprises a ticket index, a resource identifier, a strategy version number and a ticket effective height range, the authentication service module returns the authentication ticket to a client, the client carries the authentication ticket when accessing a resource, and the verification node determines whether an access request passes according to a ticket index, a revocation state and a ticket effective height range, and rejects the access request when the access request does not pass. The trusted root module is a trusted platform module, and the trusted platform module comprises a key storage area, a key derivation unit and a signature unit. 2.The server security authentication system based on blockchain trusted computing according to claim 1, wherein, ​ The key storage area pre-stores a master key, the trusted agent module submits a registration index, a block hash digest, a starting height of a block height window, and a block height window length to the trusted platform module through a local call interface, the trusted platform module performs a key derivation operation on the registration index, the block hash digest, the starting height of the block height window, and the block height window length in the key derivation unit to obtain a staged attestation key using the master key, and calculates a signature value of the attestation package based on the staged attestation key in the signature unit and returns to the trusted agent module. 3.The server security authentication system based on blockchain trusted computing according to claim 1, characterized in that, The trusted root module is a trusted execution environment, and the trusted execution environment includes a protected execution area and a key escrow area; The trusted agent module writes the registration index, the block hash digest, the starting height of the block height window, and the block height window length into the protected execution area, and the trusted execution environment performs a key derivation operation in the protected execution area to obtain a staged attestation key and writes the staged attestation key into the key escrow area; The trusted agent module writes the attestation package into the protected execution area, and the trusted execution environment calculates a signature value of the attestation package based on the staged attestation key in the protected execution area and returns to the trusted agent module. 4.The server security authentication system based on blockchain trusted computing according to claim 1, wherein, The registration contract maintains a registration record table on a blockchain network, and a registration record of the registration record table includes a registration index, an attestation public key, a server identifier, and a registration state; The revocation contract maintains a revocation record table on a blockchain network, and a revocation record of the revocation record table includes a registration index, a revocation state, and a revocation block height; The verification node reads an attestation public key from the registration contract according to a registration index and reads a revocation state and a revocation block height from the revocation contract according to the registration index before verifying the attestation package.

5. The server security authentication system based on blockchain trusted computing according to claim 4, characterized in that, The policy contract maintains a policy record table on a blockchain network, and a policy record of the policy record table includes a policy version number, a baseline commitment value, a hash algorithm identifier, and a leaf node encoding rule identifier; The baseline commitment value is a Merkle root obtained by generating a leaf node digest according to the leaf node encoding rule for a trusted baseline set and constructing a Merkle tree according to the hash algorithm; The verification node reads a baseline commitment value, a hash algorithm identifier, and a leaf node encoding rule identifier from the policy contract according to a policy version number. 6.The server security authentication system based on blockchain trusted computing according to claim 1, wherein, The authentication service module reads a current block height and a corresponding block hash digest from the blockchain network, determines the current block height as a starting height of a block height window, and determines a preset window length as a block height window length; The challenge parameter includes a client random number, a block hash digest, a starting height of a block height window, a block height window length, a policy version number, and a resource identifier; The authentication service module performs a hash operation on the challenge parameter after splicing the challenge parameter according to a preset encoding rule to obtain a challenge value, and sends the challenge parameter and the challenge value to the trusted agent module. 7.The server security authentication system based on blockchain trusted computing according to claim 1, wherein, The measurement digest collected by the trusted agent module is composed of a startup measurement digest and a running state measurement digest; The start-up metric digest is obtained by performing a hash operation on the concatenated values of the digest value of the operating system kernel image file and the digest value of the boot loading file according to a preset encoding rule; and the running state metric digest is obtained by performing a hash operation on the concatenated values of the digest value of the container image identifier and the digest value of the key service executable file according to a preset encoding rule. The metric digest is obtained by performing a hash operation on the concatenated values of the start-up metric digest and the running state metric digest according to a preset encoding rule. 8.The server security authentication system based on blockchain trusted computing according to claim 7, wherein, The key derivation function in the trusted root module takes the registration index, the block hash digest, the start height of the block height window and the block height window length as inputs, and outputs a staged attestation key derived from the root key stored in the trusted root module as a derivation root key; The trusted agent module writes the registration index, the policy version number, the block height, the resource identifier, the metric digest, the challenge parameter and the challenge value into an attestation package, and encapsulates the attestation package after the trusted root module calculates a signature value. 9.The server security authentication system based on blockchain trusted computing of claim 5, wherein, The compliance attestation is a Merkle path attestation, which includes a leaf node digest, a path node digest sequence and a node direction sequence. The leaf node digest is obtained by performing a hash operation on the concatenated values of the metric digest and the policy version number according to the corresponding encoding rule identified by the leaf node encoding rule; The verification node recalculates a recalculated root value layer by layer according to the path node digest sequence and the node direction sequence, and performs consistency checking on the recalculated root value and the baseline commitment value. 10.The server security authentication system based on blockchain trusted computing according to claim 1, wherein, The verification node generates an authentication ticket when the attestation package passes the verification and the revocation state is not revoked, the authentication ticket includes a ticket index, a registration index, a resource identifier, a policy version number, a ticket valid height range and a ticket signature value, the ticket valid height range includes a ticket start height and a ticket end height, the ticket start height is the block height when the authentication ticket is generated, and the ticket end height is the sum of the ticket start height and a preset ticket valid window length; The verification node performs a hash operation on the concatenated values of the ticket index, the registration index, the resource identifier, the policy version number and the ticket valid height range according to a preset encoding rule to obtain a ticket digest, and calculates a ticket signature value based on the ticket private key. The verification node writes the ticket index or its digest, the registration index, the policy version number and the authentication conclusion digest into a block chain network; When a client accesses a resource, the authentication ticket is carried, and the verification node determines whether the access request passes according to the ticket signature value signature verification result, the consistency of the resource identifier in the access request and the authentication ticket, whether the current block height is in the ticket valid height range and the revocation state read by the revocation contract.

Images