A compliance audit method and related device for Xinxin

Abstract

The present application relates to a kind of compliance audit method of Xinyuan and related equipment.It includes: in response to audit request, compliance attribute set is disassembled to compliance policy of Xinyuan and is normalized coding, generates policy commitment value, determines policy version number and compliance threshold, is issued to the equipment to be audited;Challenge parameter is generated, and challenge parameter and disclosure level are issued to the equipment to be audited;In trusted execution environment, obtain start chain abstract and current system configuration information, and current system configuration information is normalized coding and obtains configuration coding, and based on start chain abstract, configuration coding generates measurement vector;Based on public commitment value, challenge parameter and policy version number, generate binding message digest, generate digital signature;Based on measurement vector, digital signature, public commitment value and policy commitment value, generate zero-knowledge proof;Verify the validity of digital signature and zero-knowledge proof, output audit result.The method effectively avoids the privacy leakage of equipment, improves the authenticity and reliability of audit result.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and related equipment for auditing compliance with information technology innovation. Background Technology

[0002] As an important component of the national information security strategy, the compliance audit of the information technology application innovation industry is a key link in ensuring the safe and reliable operation of information technology application innovation systems.

[0003] In related technologies, compliance audits for IT innovation on servers, terminals, virtual machines, and various information technology devices typically employ methods such as manual verification, reporting by Agent programs pre-installed in the devices, network scanning and fingerprint recognition, and remote verification of device integrity.

[0004] However, the aforementioned domestic IT innovation compliance audit solutions have at least the following problems: serious exposure of device privacy, insufficient reliability of audit results, and lack of flexible disclosure control.

[0005] There is currently no effective solution to the aforementioned problems in the relevant technologies. Summary of the Invention

[0006] The present invention provides a method and related equipment for auditing compliance with domestic IT innovation, which at least partially solves the problems of serious leakage of device privacy and low reliability of audit results in related technologies.

[0007] To address the aforementioned problems, one aspect of this invention provides a method for auditing compliance with domestic IT innovation standards, applied to a domestic IT innovation compliance auditing system. The domestic IT innovation compliance auditing system includes a verification module deployed on a server, a measurement module deployed on the device to be audited, and a verification module. The method includes: In response to receiving an audit request for the device to be audited, the verification module decomposes the domestic IT compliance strategy into at least one set of compliance attributes according to the audit request, performs normalized encoding on the set of compliance attributes, generates a strategy commitment value based on the normalized encoded set of compliance attributes, and determines the strategy version number and compliance threshold; the strategy commitment value, the strategy version number, and the compliance threshold are then sent to the device to be audited. The verification module generates challenge parameters containing a one-time random number, a session identifier, and a verifier identifier, and sends the challenge parameters and the disclosure level indicated in the audit request to the device to be audited. The measurement module acquires the startup chain digest and current system configuration information in the trusted execution environment. It then normalizes and encodes the current system configuration information to obtain a configuration code. A measurement vector is generated based on the startup chain digest, the configuration code, and the current measurement time. A public commitment value is generated based on the measurement vector. A binding message digest is generated based on the public commitment value, the challenge parameter, and the policy version number. This binding message digest is then signed using a device proof key to obtain a digital signature. The measurement module sends the configuration code to the witness generation entity, enabling the witness generation entity to generate a corresponding member witness certificate based on the configuration code and the policy version number, and then distributes the member witness certificate to the device to be audited. The proof module generates a zero-knowledge proof within a protected, isolated space based on the measurement vector, the member witness proof, the digital signature, the public commitment value, and the policy commitment value, and returns the digital signature, the public commitment value, and the zero-knowledge proof to the verification module. The zero-knowledge proof proves that: the measurement vector and the public commitment value satisfy a commitment relationship; each configuration code in the measurement vector belongs to the set of compliance attributes after normalization of the policy commitment value; and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold. The verification module verifies the validity of the digital signature and the zero-knowledge proof, and outputs the audit results.

[0008] In some embodiments, the compliance attribute set includes one or more of the following: operating system set, CPU set, database set, and middleware set; the configuration code corresponds to the compliance attribute set and includes one or more of the following: operating system code, CPU code, database code, and middleware code. The policy commitment value is generated based on a cryptographic commitment structure, which includes a Merkle tree, a cryptographic accumulator, or a vector commitment.

[0009] In some embodiments, the method further includes: The calculation steps for the compliance score include: generating set weight values ​​corresponding to each compliance attribute set through the verification module, constructing a weight vector, and sending the weight vector, along with the policy commitment value, the policy version number, and the compliance threshold, to the device to be audited; the verification module deployed on the device to be audited generates a Boolean compliance vector based on the membership verification results of each configuration code in the measurement vector for the compliance attribute set, calculates the inner product of the Boolean compliance vector and the weight vector, and obtains the compliance score; The steps to prove that the compliance score is not lower than the compliance threshold include: using a zero-knowledge range proof algorithm to prove that the compliance score falls within a preset compliance range; wherein, the lower limit of the preset compliance range is the compliance threshold, and the upper limit is the theoretical maximum compliance score. In some of these embodiments, the device to be audited uses the SM4 algorithm to symmetrically encrypt and store the intermediate states of the member witness proof, commitment random number, and zero-knowledge proof. The communication session between the device to be audited and the verification module is encrypted using the SM4 algorithm.

[0010] In some embodiments, the method further includes: If the verification passes, a compliance token is generated by the verification module and sent to the device to be audited; wherein, the compliance token includes the audit result, policy version number, token validity period and verification party signature.

[0011] In some embodiments, the measurement module or the proof module controls the disclosure granularity of the audit results through the public output of the zero-knowledge proof based on the received disclosure level; the disclosure granularity includes at least one of pass / fail, compliance dimension information, non-compliance dimension information, or compliance score achievement status.

[0012] In some embodiments, the domestic IT compliance audit system further includes an accountability module, and the method further includes: The measurement module generates a pseudo-anonymous identifier for the device to be audited based on the device secret, audit cycle, and policy version number; wherein, the device secret is pre-installed on the device to be audited, and the audit cycle is pre-issued by the verification module or predefined by the system; When sending the digital signature, the public commitment value, and the zero-knowledge proof to the verification module, the pseudo-anonymous identifier is also sent as the identity identifier of the device to be audited. The accountability module establishes an authorization and accountability mechanism based on the SM9 cryptographic algorithm. When the regulatory authorization conditions are met, the accountability module performs the mapping of the pseudo-anonymous identifier back to the real device identifier of the device to be audited.

[0013] In some embodiments, the steps of generating a public commitment value based on the measurement vector, generating a binding message digest based on the public commitment value, the challenge parameter, and the policy version number, and signing the binding message digest using a device proof key to obtain a digital signature include: The public commitment value is obtained by calculating the measurement vector and the commitment random number using a cryptographic commitment algorithm; The SM3 algorithm is used to hash the public commitment value, the challenge parameter, and the policy version number to obtain the binding message digest. The digital signature is obtained by signing the binding message digest using the SM2 algorithm.

[0014] To address the aforementioned problems, one aspect of this invention provides a domestic IT compliance audit system, including a verification module deployed on a server, a measurement module deployed on the device to be audited, and a verification module; wherein, The verification module is configured to, in response to receiving an audit request for the device to be audited, decompose the domestic IT compliance strategy into at least one set of compliance attributes according to the audit request, perform normalized encoding on the set of compliance attributes, generate a strategy commitment value based on the normalized encoded set of compliance attributes, and determine the strategy version number and compliance threshold; send the strategy commitment value, the strategy version number, and the compliance threshold to the device to be audited; generate challenge parameters including a one-time random number, a session identifier, and a verifier identifier, and send the challenge parameters and the disclosure level indicated in the audit request to the device to be audited. The measurement module is used to obtain the startup chain digest and current system configuration information in a trusted execution environment; to normalize and encode the current system configuration information to obtain a configuration code; to generate a measurement vector based on the startup chain digest, the configuration code, and the current measurement time; to generate a public commitment value based on the measurement vector; to generate a binding message digest based on the public commitment value, the challenge parameter, and the policy version number; and to sign the binding message digest using a device proof key to obtain a digital signature. The measurement module is also used to send the configuration code to a witness generation entity, so that the witness generation entity generates a corresponding member witness certificate based on the configuration code and the policy version number, and distributes the member witness certificate to the device to be audited. The proof module is used to generate a zero-knowledge proof based on the measurement vector, the member witness proof, the digital signature, the public commitment value, and the policy commitment value within a protected isolated space, and to return the digital signature, the public commitment value, and the zero-knowledge proof to the verification module; wherein, the zero-knowledge proof is used to prove that: the measurement vector and the public commitment value satisfy a commitment relationship, each configuration code in the measurement vector belongs to the set of compliance attributes after normalization of the policy commitment value, and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold; The verification module is also used to verify the validity of the digital signature and the zero-knowledge proof returned by the proof module, and output the audit results.

[0015] To address the aforementioned problems, one aspect of this invention provides a non-transitory machine-readable medium storing computer instructions for causing a computer to execute any of the aforementioned domestic IT compliance audit methods.

[0016] The beneficial effects of this invention are as follows: Upon receiving an audit request for the device to be audited, the verification module decomposes the domestic IT compliance strategy into at least one set of compliance attributes based on the audit request. The set of compliance attributes is then normalized and encoded. A strategy commitment value is generated based on the normalized and encoded set of compliance attributes, and a strategy version number and compliance threshold are determined. The strategy commitment value, strategy version number, and compliance threshold are then sent to the device to be audited. The verification module generates challenge parameters containing a one-time random number, session identifier, and verifier identifier, and sends the challenge parameters and the disclosure level indicated in the audit request to the device to be audited. The measurement module obtains the startup chain digest and current system configuration information in the trusted execution environment. The current system configuration information is normalized and encoded to obtain a configuration code. A measurement vector is generated based on the startup chain digest, configuration code, and current measurement time. A public commitment value is generated based on the measurement vector. Finally, a public commitment value is generated based on the public commitment value, challenge parameters, and strategy version number. The system generates a binding message digest and signs it using the device's proof key to obtain a digital signature. A configuration code is sent to the witness generation entity via the measurement module, enabling the entity to generate a corresponding member witness certificate based on the configuration code and policy version number, and then distributes the member witness certificate to the device to be audited. A zero-knowledge proof is generated within a protected isolated space by the proof module based on the measurement vector, member witness certificate, digital signature, public commitment value, and policy commitment value. The digital signature, public commitment value, and zero-knowledge proof are then returned to the verification module. The zero-knowledge proof proves that: the measurement vector and public commitment value satisfy a commitment relationship; each configuration code in the measurement vector belongs to the set of compliance attributes after normalization of the policy commitment value; and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold. The verification module verifies the validity of the digital signature and zero-knowledge proof and outputs the audit results. This approach overcomes the problems of serious device privacy leakage and low reliability of audit results in related domestic IT compliance audit solutions.This invention employs an auditing process involving policy commitment generation and distribution, dynamic challenge binding, trusted execution environment measurement and signing, zero-knowledge compliance proof generation, signature verification, and zero-knowledge proof output. This process ensures rule confidentiality through policy commitment values, guarantees session real-time performance and unforgeability through challenge parameter binding, ensures the authenticity of input states through trusted measurement, and guarantees the verifiability of compliance conclusions without privacy leaks through zero-knowledge proofs. The introduction of disclosure-level instructions minimizes output results. This allows for the proof that a device's current true state meets the domestic IT compliance policy (including multi-dimensional set membership relationships and threshold compliance) without exposing the device's complete configuration plaintext to the verifier. It also supports outputting the minimum necessary audit results at the disclosure level and effectively prevents replay and cross-session reuse attacks through the binding of challenge parameters and signatures. This achieves the technical effects of avoiding device privacy leaks, improving the reliability of audit results, and providing flexible disclosure granularity control.

[0017] Details of one or more embodiments of the present invention are set forth in the following drawings and description, so that other features, objects and advantages of the invention will be more readily understood. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the main process of a domestic IT compliance audit method according to one embodiment of the present invention; Figure 2 This is a schematic diagram of the main modules of a domestic IT compliance audit system according to one embodiment of the present invention; Figure 3 This is a partial module interaction diagram of a domestic IT compliance audit system, which is yet another embodiment of the present invention. Figure 4 This is a partial module interaction diagram of a domestic IT compliance audit system, which is yet another embodiment of the present invention. Figure 5 This is a schematic diagram of the structure of an electronic device according to an embodiment of the invention. Detailed Implementation

[0020] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the invention. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention.

[0021] In related technologies, the following solutions are commonly used for compliance audits of IT innovation for servers, terminals, virtual machines and various information technology devices: (1) Manual verification solution: Auditors check whether the configuration of the operating system, CPU, database, middleware and other components of the device meets the IT innovation compliance requirements by logging into the device, viewing system information, software list and other methods. This solution is inefficient and requires auditors to obtain complete configuration information of the device, which poses a serious risk of privacy exposure. (2) Agent reporting solution: By pre-installing an Agent program in the device to be audited, the Agent regularly collects the software and hardware configuration information of the device and sends it back to the audit center. Although this solution improves audit efficiency, the device needs to expose the complete configuration plaintext to the auditor, including the operating system version, CPU model, database name and version, middleware information and so on. This information often involves the company's trade secrets and core asset information. Once leaked or misused, it will pose a serious threat to the company's security. In addition, the data reported by the Agent lacks strong binding proof with the current real status of the device. Attackers can deceive the audit system by fabricating reported data. (3) Network scanning and fingerprinting scheme: The auditor remotely infers the software stack information of the device through LAN scanning, port probing, service fingerprinting and other means. This scheme also requires a large amount of device configuration information, and due to the inferential nature of the scanning results, its accuracy and reliability are low. It cannot prove the authenticity of the device's "current state", and it is also difficult to effectively bind the scanning results with the current audit session. It is vulnerable to replay attacks and man-in-the-middle attacks. (4) Remote proof method based on TPM (Trusted Platform Module) / TEE (Trusted Execution Environment): It is mainly used to prove the integrity of the device's startup chain and the platform's trusted state. However, existing remote proof schemes usually output plaintext measurement results such as the device's PCR value (Platform Configuration Registers). The auditor can still obtain the specific configuration information of the device. At the same time, existing remote proof schemes cannot directly prove "whether the device meets a specific information technology innovation compliance strategy", such as whether the device belongs to the allowed set of operating systems or whether it uses a compliant database. Furthermore, existing solutions lack a mechanism for selectively disclosing audit results after verification, often resulting in auditors obtaining far more information than necessary, thus posing a risk of device privacy breaches.

[0022] Based on the auditing schemes documented above, at least the following problems can be identified: Severe privacy exposure: Regardless of whether manual verification, agent reporting, or network scanning is used, the auditor needs to obtain the complete plaintext configuration of the device, leading to excessive exposure of sensitive information such as the device's operating system, CPU, database, and middleware, violating the principle of data minimization. Insufficient audit reliability: The schemes in these technologies struggle to prove that "the current state of the device is genuine, not forged, and bound to this audit session." Agent-reported data can be tampered with or replayed, network scan results can be forged, and traditional remote proofs lack a strong binding mechanism for dynamic challenges from the verifying party. Lack of flexible disclosure control: Audit results obtained by the auditor often contain a large amount of redundant information, unable to output only the minimum necessary information such as "pass / fail," "compliance dimension," or "non-compliance dimension" as needed, failing to meet the differentiated requirements under different security levels. A contradiction between privacy protection and accountability: Completely anonymous auditing can protect device identity privacy but cannot meet the needs of post-event supervision and dispute tracing; completely real-name auditing increases the risk of exposing device identity information, making it difficult to reconcile the two.

[0023] To address the aforementioned issues, this invention provides a method for auditing compliance with domestic IT innovation standards, applied to a domestic IT innovation compliance auditing system. This system includes a verification module deployed on the server side, a measurement module deployed on the device to be audited, and a verification module. Figure 1 As shown, the main methods for compliance auditing of information technology innovation mainly include: Step S101: In response to receiving an audit request for the device to be audited, the verification module decomposes the domestic IT compliance strategy into at least one set of compliance attributes according to the audit request, performs standardized coding on the set of compliance attributes, generates a strategy commitment value based on the standardized coded set of compliance attributes, and determines the strategy version number and compliance threshold; and sends the strategy commitment value, strategy version number, and compliance threshold to the device to be audited. Step S102: Use the verification module to generate challenge parameters containing a one-time random number, session identifier, and verifier identifier, and send the challenge parameters and the disclosure level indicated in the audit request to the device to be audited; Step S103: The measurement module obtains the startup chain digest and current system configuration information in the trusted execution environment. The current system configuration information is normalized and encoded to obtain a configuration code. A measurement vector is generated based on the startup chain digest, configuration code, and current measurement time. A public commitment value is generated based on the measurement vector. A binding message digest is generated based on the public commitment value, challenge parameters, and policy version number. The binding message digest is signed using the device proof key to obtain a digital signature. The measurement module sends the configuration code to the witness generation entity, so that the witness generation entity can generate the corresponding member witness certificate based on the configuration code and policy version number, and distribute the member witness certificate to the device to be audited. Step S104: The proof module generates a zero-knowledge proof within the protected isolated space based on the measurement vector, member witness proof, digital signature, public commitment value, and policy commitment value, and returns the digital signature, public commitment value, and zero-knowledge proof to the verification module. The zero-knowledge proof is used to prove that: the measurement vector and the public commitment value satisfy the commitment relationship; each configuration code in the measurement vector belongs to the set of compliance attributes after normalization of the policy commitment value; and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold. Step S105: Verify the validity of the digital signature and zero-knowledge proof based on the verification module, and output the audit results.

[0024] Based on the above settings, the audit steps, including policy commitment generation and distribution, dynamic challenge binding, trusted execution environment measurement and signing, zero-knowledge compliance proof generation, verification of signatures and zero-knowledge proofs, and output of audit results, utilize policy commitment values ​​and member witness proofs to ensure that rules are not leaked and that devices have proof capabilities. The binding of challenge parameters and signatures ensures the real-time nature and unforgeability of sessions. Trusted measurement ensures the authenticity of input states. Zero-knowledge proofs generated in a protected isolated space ensure the verifiability of compliance conclusions without leaking privacy. The introduction of disclosure-level instructions ensures the minimization of output results. This enables the proof that the current true state of the device meets the domestic IT innovation compliance policy (including multi-dimensional set membership relationships and threshold compliance) without exposing the complete plaintext configuration of the device to the verifier. It also supports outputting the minimum necessary audit results according to the disclosure level. Furthermore, the binding of challenge parameters and signatures effectively prevents replay and cross-session reuse attacks, achieving the technical effects of avoiding device privacy leaks, improving the authenticity and reliability of audit results, and providing flexible disclosure granularity control.

[0025] The witness generation entity mentioned above can be any one of the following: an independent policy compilation module, an independent witness server, a trusted third-party witness service, or a cryptographic auxiliary module specifically used to generate member proof witnesses.

[0026] Specifically, according to an embodiment of the present invention, based on the above step S101, the verification module decomposes the domestic IT compliance strategy into a set of compliance attributes and performs standardized encoding according to the audit request, generates a strategy commitment value, and determines the strategy version number and compliance threshold, which are then sent to the device to be audited. Since the set of compliance attributes is standardized and encoded to generate the strategy commitment value, the device can subsequently prove its compliance based on the commitment value without needing to obtain the plaintext content of the rules, avoiding the exposure of the strategy plaintext during transmission. At the same time, the issuance of the strategy version number and compliance threshold enables the device to perform compliance self-verification for a specific version of the audit strategy, and the compliance threshold condition provides a quantitative basis for subsequent compliance score judgment.

[0027] In some embodiments, based on step S102 above, a challenge parameter containing a one-time random number, a session identifier, and a validator identifier is generated by the verification module, and the challenge parameter and the disclosure level indicated in the audit request are sent to the device to be audited. The introduction of the unpredictable dynamic factor (one-time random number) effectively prevents replay attacks using old proofs. The session identifier and validator identifier bind subsequent proofs to the current session and the current validator, preventing proofs from being reused across sessions or validators. Simultaneously, after the disclosure level is sent, the device to be audited can control the granularity of subsequent audit results output according to the disclosure level, achieving minimal disclosure on demand and avoiding the leakage of redundant information.

[0028] In some examples, based on step S103 above, a measurement module deployed in the device to be audited obtains the startup chain digest and current system configuration information in a trusted execution environment. This information is then normalized and encoded to generate a measurement vector. A public commitment value is generated based on the measurement vector, and a binding message digest is generated based on the public commitment value, challenge parameters, and policy version number. Finally, a digital signature is obtained using the device's proof key. Specifically, performing measurements in a trusted execution environment ensures the authenticity and integrity of the measurement values, preventing the device from reporting forged states. The measurement vector contains the startup chain digest, configuration code, and current measurement time, reflecting the complete state of the device after startup. The introduction of the public commitment value allows the verifier to independently verify the signature without needing to know the plaintext of the measurement vector. The binding message digest mixes the public commitment value, a one-time random number, a session identifier, a verifier identifier, and a policy version number, ensuring that the signature result simultaneously contains the commitment to the measurement vector, session information, and policy information. Any change to any of these elements will invalidate the signature, thus ensuring the validity of the proof and preventing replay attacks.

[0029] In some implementations, the measurement module obtains the startup chain digest and current system configuration information in the trusted execution environment. After normalizing and encoding the current system configuration information to obtain a configuration code, this configuration code is sent to the witness generation entity. This entity (which, depending on the actual deployment, may be a policy compilation module deployed on the server or a trusted third-party witness service) generates corresponding member witness proofs (w_os, w_cpu, w_db, w_mw) based on the normalized code (i.e., the configuration code) and the current policy version. The member witness proofs are then returned to the device under audit via a secure channel. This allows the proof module deployed on the device under audit to generate zero-knowledge proofs based on the measurement vectors and member witnesses. When the policy version is updated, the corresponding member witness proofs are updated synchronously with the policy commitment value. This further ensures that the verification module only receives digital signatures, public commitment values, zero-knowledge proofs, and necessary disclosure results, without directly obtaining the configuration code, thus avoiding the risk of configuration code leakage.

[0030] In some examples, based on step S104 above, a proof module deployed in the device to be audited generates a zero-knowledge proof within a protected, isolated space, based on the measurement vector, member witness proof, digital signature, public commitment value, and policy commitment value. This zero-knowledge proof proves that: the measurement vector and the public commitment value satisfy a commitment relationship; each configuration code in the measurement vector belongs to the compliance attribute set corresponding to the policy commitment value; and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold. The zero-knowledge proof itself has the characteristic of "proving only the conclusion without revealing the secret input." By using the configuration code in the measurement vector as the secret input to be proven, and the policy commitment value and compliance threshold as public inputs, and verifying the membership relationship through member witness proof, a proof can be generated that only shows the fact that "the configuration code belongs to the compliance attribute set and the score meets the standard," without exposing the specific code content. Simultaneously, the digital signature, public commitment value, and zero-knowledge proof are submitted to the verification module. After verifying the signature, the verification module can confirm the validity of the device and session, and then combine this with the zero-knowledge proof to confirm configuration compliance, thereby achieving the goal of proving device compliance to the verification party without revealing the plaintext configuration. Digital signatures, as one of the inputs to zero-knowledge proofs, ensure that the current system state of the device being proven does indeed correspond to the audited device that has been actually measured and bound to a session. It should also be noted that the proof module can also be deployed in a trusted execution environment on the audited device, enabling the generation of zero-knowledge proofs within the trusted execution environment. This prevents attackers from forging compliant zero-knowledge proofs through memory tampering, debug injection, or context substitution.

[0031] In some embodiments, based on step S105 above, the validity of the digital signature and the validity of the zero-knowledge proof are verified by the verification module, and an audit result is output. Specifically, verifying the validity of the digital signature can confirm whether the bound message digest is signed by a legitimate device proof key and has not been tampered with; thereby confirming the authenticity of the public commitment value and the session information it is bound to; verifying the validity of the zero-knowledge proof can confirm that the device configuration meets the compliance attribute set corresponding to the policy commitment value and the score is not lower than the threshold, while confirming the consistency between the measurement vector and the public commitment value; if all of the above verifications pass, the verification module has sufficient reason to confirm that the current device state is real, the configuration is compliant, and the session is valid, thereby outputting a true and reliable audit result.

[0032] According to a specific embodiment of the present invention, when submitting a zero-knowledge proof, the device to be audited also submits a public commitment value, commit_M, generated based on a measurement vector, to the verification module; the digital signature is a signature generated by the device's proof key for SM3(commit_M || nonce || session_id || verifier_id || policy_version); the zero-knowledge proof further proves that its internally used private measurement vector M and commitment random number r satisfy Com(M;r)=commit_M, thereby enabling the verification module to complete the signature verification without disclosing the plaintext of the measurement vector, and ensuring the cryptographic closed loop between identity, state, and proof is established.

[0033] In some embodiments, the aforementioned compliance attribute set includes one or more of the following: operating system set, central processing unit set, database set, and middleware set; the aforementioned configuration code corresponds to the compliance attribute set and includes one or more of the following: operating system code, central processing unit code, database code, and middleware code; the aforementioned policy commitment value is generated based on a cryptographic commitment structure, which includes a Merkle tree, a cryptographic accumulator, or a vector commitment.

[0034] Based on the above settings, specific examples are provided regarding the content or form of compliance attribute sets, configuration codes, and policy commitment values. Specifically, by decomposing the domestic IT compliance policy into multiple independent compliance attribute sets such as operating system, central processing unit, database, and middleware, a structured compliance standard for decomposing the domestic IT compliance policy is established. By encoding the actual configuration of the device to be audited into configuration codes corresponding to the dimensions of the compliance attribute sets, an isomorphic mapping between the actual state of the device and compliance requirements is established. By using cryptographic commitment structures such as Merkle trees (a core data structure in cryptography and distributed systems), cryptographic accumulators, or vector commitments to generate policy commitment values, it is possible to support subsequent zero-knowledge proofs of membership relationships without revealing the specific compliance whitelist. It is understood that, based on the above specific limitations, the auditing method provided by this invention can support multi-dimensional, cryptographically verifiable compliance proofs that do not expose the plaintext of the policy.

[0035] In some embodiments, if the device to be audited does not have a database or middleware deployed, the corresponding configuration code can be mapped to a null code, a default code, or a "not deployed" code, and the policy determines whether it participates in membership verification and compliance score calculation.

[0036] Specifically, according to embodiments of the present invention, since the compliance requirements for domestically developed IT equipment often involve multiple independent components (e.g., the operating system must be a specific version, the CPU must be a specific model, etc.), the domestically developed IT compliance strategy is broken down into corresponding sets of components. This makes the audit object no longer a general device as a whole, but a combination of one or more independent dimensions such as the operating system, central processing unit, database, and middleware. At the same time, this multi-dimensional structure allows the verification party to perform compliance verification only for a specific dimension (such as the operating system) in subsequent steps, without having to process information from all dimensions, thus creating conditions for selective disclosure and failure category identification.

[0037] Meanwhile, by setting the actual configuration information of the device under audit, such as its operating system, CPU, database, and middleware, and standardizing the encoding according to the same dimensions as the compliance attribute set, a corresponding configuration code is obtained. This establishes an isomorphic mapping relationship between the actual state of the device and the commitment value of the compliance policy, ensuring the feasibility of comparison and proof. Furthermore, the standardization of the encoding also avoids misjudgments caused by naming differences (such as capitalization and aliases).

[0038] Furthermore, a Merkle tree can use the hash value of each element in the set as a leaf node to generate a root as a commitment value. Any element and its path can prove its membership in the set without exposing other elements. A cryptographic accumulator can aggregate the entire set into a constant-sized value and support zero-knowledge proofs of membership. Vector commitments can also bind a set of values ​​and support positional proofs. By limiting the policy commitment value to not directly expose the plaintext elements of the compliance attribute set, but instead calculating it through cryptographic commitment structures such as Merkle trees, cryptographic accumulators, or vector commitments, the policy commitment value possesses the characteristics of hiding the original set element content while supporting efficient membership verification. It is understandable that using the above structures to generate policy commitment values ​​allows devices to generate membership proofs without disclosing the compliance whitelist, and verifiers can verify the validity of these proofs, thereby protecting the privacy of the compliance policy itself.

[0039] In some embodiments, the calculation steps corresponding to the compliance score include: generating set weight values ​​corresponding to each compliance attribute set through the verification module, constructing a weight vector, and sending the weight vector, along with the policy commitment value, policy version number, and compliance threshold, to the device to be audited; the proof module deployed on the device to be audited generates a Boolean compliance vector based on the verification results of the membership relationship of each configuration code in the measurement vector, calculates the inner product of the Boolean compliance vector and the weight vector, and obtains the compliance score; correspondingly, the step of proving that the compliance score is not lower than the compliance threshold includes: using a zero-knowledge scope proof algorithm to prove that the compliance score falls within a preset compliance range; wherein, the lower limit of the preset compliance range is the compliance threshold, and the upper limit of the range is the theoretical maximum compliance score.

[0040] Based on the above setup, a flexible compliance determination mechanism based on the inner product of weight vectors and Boolean compliance vectors is provided, and the threshold proof is concretized as a zero-knowledge scope proof (RangeProof). Specifically, the verification module defines the importance of different dimensions in the comprehensive evaluation by distributing weight vectors w=(a,b,c,d) corresponding to each set of compliance attributes; the proof module deployed on the device to be audited generates a Boolean compliance vector b=(b_os,b_cpu,b_db,b_mw) composed of 0 / 1 according to the verification results of the membership relationships of the compliance attribute sets by each configuration code; by calculating the inner product of the Boolean compliance vector and the weight vector, a quantifiable comprehensive compliance score is obtained.<b,w> The compliance score is then proven to fall within a preset compliance range [T, Wmax] using a zero-knowledge scope proof algorithm (such as Bulletproofs or an equivalent mechanism) (the lower limit of the preset compliance range is the compliance threshold T, and the upper limit is the theoretical maximum score Wmax), without disclosing the scores of each sub-item, the specific configuration codes, and the corresponding membership details to the verification module.

[0041] In domestic IT compliance audits, different components may have varying degrees of importance to overall compliance (for example, operating system compliance may be more critical than middleware compliance). By explicitly distributing weight vectors, the verification module can convey its evaluation criteria to the audited device, enabling the device to understand the importance of different compliance dimensions in the overall evaluation and providing a weighted basis for subsequent calculation of the comprehensive compliance score. Furthermore, the distribution of weight vectors is synchronized with the policy commitment value, policy version number, and compliance threshold, ensuring that the device simultaneously obtains rule commitments, version identifiers, judgment criteria, and dimension importance coefficients within the same policy framework, avoiding inconsistencies caused by fragmented information transmission.

[0042] The calculation of compliance scores and the proof of their scope are both completed locally on the device. The specific compliance status details, sub-scores, or plaintext configuration codes for each dimension are not exposed to the verification module. The module only outputs the final conclusion that "the compliance score falls within the compliance range" through the scope proof, further protecting device privacy. Simultaneously, because zero-knowledge scope proof is used, the verification module cannot deduce the specific compliance score value or contribution of each dimension; it can only be certain that the score meets the standard, thus achieving a balance between privacy protection and flexible compliance judgment.

[0043] In some of these embodiments, the device under audit uses the SM4 algorithm to symmetrically encrypt and store the intermediate states of member witness proofs, commitment random numbers, and zero-knowledge proofs; the communication session between the device under audit and the verification module is encrypted and protected using the SM4 algorithm.

[0044] Based on the above settings, the national cryptographic algorithm SM4 is used to provide confidentiality protection for sensitive data and communication links on the device side. Specifically, member witness proofs (such as Merkle paths and accumulator witness values), commitment random numbers (used to generate public commitment values), and intermediate data in the zero-knowledge proof generation process are all highly sensitive cryptographic materials that may be exploited by attackers. Using the SM4 algorithm for symmetric encryption storage prevents local file system leaks, memory cold start attacks, or theft by malicious processes. Simultaneously, the communication sessions between the audited device and the verification module (including policy issuance, challenge parameter transmission, proof submission, token return, etc.) are protected by SM4 encryption, resisting link eavesdropping, man-in-the-middle attacks, and replay variant attacks.

[0045] The SM4 algorithm is a symmetric block cipher standard issued by the State Cryptography Administration of China, and its hardware instruction set and software implementation have been widely deployed in the domestic IT innovation ecosystem. By introducing SM4 encrypted storage and session protection, this invention not only enhances the overall system's anti-tampering and anti-theft capabilities, but also further demonstrates complete adaptation to the national cryptographic algorithm system, improving its engineering feasibility in the domestic IT innovation environment.

[0046] In some embodiments, the method further includes: if the verification is successful, generating a compliance token through the verification module and sending the compliance token to the device to be audited; wherein the compliance token includes the audit result, policy version number, token validity period and verification party signature.

[0047] Based on the above settings, in addition to outputting the audit results, an operable and verifiable credential is provided for subsequent business systems (such as access control and continuous monitoring). This compliance token is both a cryptographic solidification of the audit conclusions and a portable credential for the audited device to subsequently prove its compliance status to other systems.

[0048] In this embodiment of the invention, the generation of the compliance token depends on the condition of successful verification, which ensures that the compliance token itself always represents a real and valid compliance audit result.

[0049] In some embodiments, the compliance token encapsulates the audit result (i.e., "pass" or a corresponding audit result), the policy version number used, the token's validity period, and the signature of the verification module. The audit result field directly indicates whether the audited device is compliant, allowing for rapid system judgment. The policy version number field binds the compliance token to the domestic IT compliance policy upon which the audit is based, preventing the audited device from using an older policy version of the compliance token to circumvent the new policy's checks. The compliance token validity period field limits the token's usable time window, preventing indefinite abuse after a single successful verification and meeting continuous compliance regulatory requirements. The verifier's signature provides non-repudiation: any third party can verify the authenticity of the compliance token using the verifier's public key, confirming that it was indeed issued by a legitimate verification module and that its content has not been tampered with.

[0050] In some of these embodiments, the measurement module or proof module controls the disclosure granularity of the audit results through the public output of zero-knowledge proofs based on the received disclosure level; the disclosure granularity includes at least one of pass / fail, compliance dimension information, non-compliance dimension information, or compliance score achievement status.

[0051] Based on the above settings, a configurable, minimum-necessary audit result output mechanism based on disclosure level is provided. Specifically, the measurement module or proof module controls the granularity of the audit results that the verification module can ultimately obtain by selecting the public output content of the zero-knowledge proof according to the disclosure level issued in advance by the verification module. Optional granularities include at least one of pass / fail, compliance dimension information, non-compliance dimension information, and compliance score achievement status. This mechanism ensures that the verification module can only obtain information matching its permissions in each audit, thereby meeting the differentiated privacy protection needs under different security level scenarios.

[0052] According to embodiments of the present invention, zero-knowledge proofs require the disclosure of some information (e.g., proposition declarations, commitment values, and some parameters) during the verification process for the verification module to check, but the specific secret inputs of the proof are not disclosed. By adjusting the public outputs of the zero-knowledge proof, such as choosing whether to output the compliance status of each dimension, whether to only output whether the overall score meets the standard, or whether to output the major categories of non-compliant dimensions, the information that the verification module can obtain after verification can be precisely controlled. Since the disclosure level is issued by the verification module when an audit request is made, the measurement module or the proof module implements on-demand disclosure according to the disclosure level.

[0053] The disclosure granularity provided in this embodiment of the invention can cover various information levels. For example, it can only inform the verification module whether the audit passed (pass / fail), or inform which dimensions are compliant and which dimensions are non-compliant, or inform whether the compliance score meets the standard without giving a specific score, or any combination of the above. This hierarchical disclosure design enables the verification module to obtain the minimum necessary information according to actual business needs.

[0054] According to a specific embodiment of the present invention, pass / fail is the coarsest-grained conclusion, indicating only the overall compliance of the device under audit without disclosing any dimensional details. Compliance dimension information informs the verification module which dimensions are compliant (e.g., operating system and CPU compliance), but hides the specific coding. Non-compliance dimension information indicates which dimensions are non-compliant (e.g., database non-compliance), helping the verification module locate problems without revealing the specific model. Compliance score achievement status only indicates whether the score is not lower than the threshold, without disclosing the score value or the specific contribution of each dimension. These granularities can be used individually or in combination, encoded through the public output of zero-knowledge proofs. The verification module can read the corresponding information based on the public output, but cannot obtain finer-grained details.

[0055] In some embodiments, the aforementioned domestic IT compliance audit system also includes an accountability module. The method further includes: generating a pseudo-anonymous identifier for the device to be audited based on the device secret, audit cycle, and policy version number via a measurement module; wherein the device secret is pre-installed on the device to be audited, and the audit cycle is pre-issued by the verification module or predefined by the system; when sending the digital signature, public commitment value, and zero-knowledge proof to the verification module, the pseudo-anonymous identifier is also sent as the identity identifier of the device to be audited; wherein the accountability module establishes a permission accountability mechanism based on the SM9 cryptographic algorithm, and when regulatory permission conditions are met, the accountability module maps the pseudo-anonymous identifier back to the real device identifier of the device to be audited.

[0056] Based on the above settings, a pseudo-anonymous identity mechanism that balances privacy protection and auditability is provided, and an authorization and accountability mechanism based on the SM9 identifier cryptography algorithm is introduced. Specifically, in the regular audit process, the device uses a pseudo-anonymous identifier generated based on the device secret, audit cycle, and policy version number to replace the real device identifier. The verification module can only see this temporary anonymous identity and cannot associate it with the device's real information. However, when regulatory permission conditions are met, the authorization and accountability module can map the pseudo-anonymous identifier back to the real device identifier based on the SM9 identifier cryptography system, thereby enabling post-event traceability and responsibility determination. This mechanism takes into account both identity privacy protection in daily audits and compliance and accountability needs in special scenarios.

[0057] One of the technical dilemmas faced in the compliance audit process of information technology innovation is that complete anonymity leads to the inability to trace responsibility, while complete real-name authentication exposes device privacy. This feature introduces a pseudo-anonymous identifier as an intermediate identity, which provides triple isolation in terms of time (valid only in the current audit cycle), space (visible only to the current verification module), and permissions (based on the SM9-based permission and accountability system to control mapping permissions).

[0058] Because the pseudo-anonymous identifier is bound to the device secret, audit cycle, and policy version number, identifiers from different devices and different cycles are independent, preventing cross-session device profiling. The verification module only encounters the pseudo-anonymous identifier during normal operations and cannot obtain the real device identifier, thus meeting privacy protection requirements. The accountability module, as an independent trusted entity, establishes a permission-based accountability system based on the SM9 identifier cryptographic algorithm: the verification module or the auditor can authenticate the accountability module's identity through the SM9 identifier; the accountability module uses the SM9 private key to sign and verify deanonymization requests, ensuring that only legally authorized entities can trigger mapping operations, thereby further enhancing the controllability and legality of accountability actions.

[0059] Understandably, this mechanism does not require modification to the normal operating logic of the verification module. The verification module always uses pseudo-anonymous identifiers for session management, while the accountability module acts as a bypass facility, providing on-demand mapping capabilities. The introduction of SM9 makes permission and accountability independent of traditional public key infrastructure, reducing certificate management overhead and making it more suitable for identifier-driven security systems in the context of domestic IT innovation.

[0060] Therefore, the above-mentioned technical features achieve both privacy protection in routine audits and device accountability in special circumstances with minimal system complexity. Furthermore, the SM9 identifier cryptographic algorithm enhances the security and deployment flexibility of permission accountability control, thus solving the core problem of the incompatibility between anonymity and accountability in related technologies.

[0061] In some embodiments, the steps of generating a public commitment value based on a measurement vector, generating a binding message digest based on the public commitment value, challenge parameters, and policy version number, and signing the binding message digest using a device proof key to obtain a digital signature include: calculating the measurement vector and commitment random number using a cryptographic commitment algorithm to obtain a public commitment value; hashing the public commitment value, challenge parameters, and policy version number using the SM3 algorithm to obtain a binding message digest; and signing the binding message digest using the SM2 algorithm to obtain a digital signature.

[0062] Based on the above settings, a specific implementation method for challenge-bound signatures based on public commitment values ​​and national cryptographic algorithms is provided to ensure joint commitment and anti-counterfeiting protection of device status and audit session policies, while solving the technical problem that the verification module cannot independently verify signatures. Specifically, the device to be audited first uses a cryptographic commitment algorithm (such as hash-based commitment or Pedersen commitment) to calculate the measurement vector and commitment random number to obtain a public commitment value. This public commitment value hides the plaintext content of the measurement vector but binds its value. Then, SM3 is used to hash the public commitment value, challenge parameters, and policy version number to obtain a bound message digest. Then, SM2 is used to sign the digest to obtain a digital signature. The subsequent verification module can verify the digital signature to confirm at once: the signing device identity is legitimate, the public commitment value is bound to the current session and policy version, and all the above information has not been tampered with during transmission. Since the verification module can complete the signature verification independently without obtaining the plaintext of the measurement vector, a closed loop of signature verification is realized.

[0063] The SM3 algorithm is a cryptographic hash function with collision resistance (it's difficult to find two different inputs that produce the same output) and one-wayness (it's impossible to deduce the original input from the digest). Using the public commitment value, challenge parameters, and policy version number as inputs to SM3 ensures that any change in any of these data (such as changing the one-time random number, modifying a configuration code in the measurement vector (causing a change in the public commitment value), or using a different policy version) will lead to unpredictable changes in the digest value. Simultaneously, the fixed output length of the hash calculation facilitates subsequent signature operations, avoiding the inefficiency and insecurity of directly signing variable-length original data. Through the binding effect of SM3, the digital signature subsequently generated by the proof module actually simultaneously commits to multi-dimensional information such as device status, audit session, and policy version. Furthermore, compared to directly hashing the measurement vector, introducing the public commitment value allows the verification module to complete independent signature verification without touching the plaintext device configuration. The binding nature of the public commitment value itself ensures that if the measurement vector is tampered with, the public commitment value will also change accordingly, thus locking in the true state of the device at the signature level.

[0064] The SM2 algorithm described above is an elliptic curve cryptography-based public-key cryptography algorithm whose signature process is mathematically unforgeable. The device authentication key serves as the device's identity credential and is held only by legitimate devices. Signing the bound message digest is equivalent to the device endorsing the authenticity of the digest's content (especially the publicly committed value). After receiving the signature, the verification module uses the SM2 signature verification algorithm to confirm: whether the signature was generated by a legitimate device key (identity authentication), whether the digest content was modified during transmission (integrity protection), and whether the signature corresponds to the specific challenge and publicly committed value of this session (preventing replay attacks). Due to the asymmetry of SM2 signatures, even if the verification module or an attacker obtains the signature, they cannot forge the device's private key to generate other valid signatures, thus ensuring the uniqueness of the device's identity and the non-repudiation of the signature.

[0065] It is also understandable that the above steps implement an enhanced cryptographic binding strategy: using hash alone can only guarantee data integrity but cannot prove the source, and using signature alone can authenticate identity but cannot bind session dynamics. However, by introducing a public commitment value, the cryptographic commitment of the measurement vector is bound to the signature, so that the signature is not only a confirmation of the device identity, but also a confirmation of the entire audit context (state commitment, session, policy). Subsequent verification modules only need to verify the digital signature to simultaneously obtain the following security guarantees: verification independence (the verification module does not need to obtain the plaintext of the measurement vector, and can complete the signature verification based solely on the public commitment value, forming a complete verification closed loop), authenticity (the validity of the digital signature proves that the public commitment value comes from a trusted device (private key uniqueness), integrity (the hash digest and signature together ensure that the public commitment value, challenge parameters, and policy version have not been modified during transmission), anti-replay (a one-time random number is included in the SM3 digest binding, making old signatures unable to be directly used for new challenges), session locking (the session identifier and the verifier identifier are bound to prevent the proof from being abused by other sessions or verifiers), policy alignment (the policy version number participates in the digest, preventing the device from using an old version policy to pass the audit), and privacy protection (the plaintext of the measurement vector never leaves the device, and the verification module only accesses its public commitment value, effectively preventing configuration leakage).

[0066] The above-described information technology innovation compliance audit method provided in this embodiment of the invention, in response to receiving an audit request for the device to be audited, uses a verification module to decompose the information technology innovation compliance strategy into at least one set of compliance attributes according to the audit request, performs normalized encoding on the compliance attribute set, generates a strategy commitment value based on the normalized encoded compliance attribute set, and determines the strategy version number and compliance threshold; the strategy commitment value, strategy version number, and compliance threshold are then sent to the device to be audited; the verification module generates challenge parameters containing a one-time random number, session identifier, and verifier identifier, and sends the challenge parameters and the disclosure level indicated in the audit request to the device to be audited; the measurement module obtains the startup chain digest and current system configuration information in a trusted execution environment, performs normalized encoding on the current system configuration information to obtain a configuration code, generates a measurement vector based on the startup chain digest, configuration code, and current measurement time, and generates a public commitment value based on the measurement vector; based on the public commitment value, challenge parameters, and policy... The system generates a binding message digest using a simplified version number and signs the binding message digest using the device proof key to obtain a digital signature. The measurement module sends a configuration code to the witness generation entity, enabling the witness generation entity to generate a corresponding member witness certificate based on the configuration code and policy version number, and then distributes the member witness certificate to the device to be audited. The proof module generates a zero-knowledge proof within a protected isolated space based on the measurement vector, member witness certificate, digital signature, public commitment value, and policy commitment value, and returns the digital signature, public commitment value, and zero-knowledge proof to the verification module. The zero-knowledge proof is used to prove that: the measurement vector and public commitment value satisfy a commitment relationship; each configuration code in the measurement vector belongs to the compliance attribute set after normalization of the policy commitment value; and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold. The verification module verifies the validity of the digital signature and zero-knowledge proof and outputs the audit results. It enables the verification of a device's current true state to meet the domestic IT innovation compliance strategy (including multi-dimensional set membership relationships and threshold compliance) without exposing the complete plaintext configuration of the device to the verification party. It also supports outputting the minimum necessary audit results according to the disclosure level, and effectively prevents replay and cross-session reuse attacks by challenging the binding of parameters and signatures. It achieves the technical effects of avoiding device privacy leakage, improving the authenticity and reliability of audit results, and providing flexible disclosure granularity control.

[0067] Based on the above-described method for auditing compliance with information technology innovation provided in the embodiments of the present invention, the embodiments of the present invention also provide a system for auditing compliance with information technology innovation, such as... Figure 2 As shown, the IT innovation compliance audit system 200 includes: Verification module 201 is used to respond to receiving an audit request for the device to be audited, decompose the domestic IT compliance strategy into at least one set of compliance attributes according to the audit request, perform normalized encoding on the set of compliance attributes, generate a strategy commitment value based on the normalized encoded set of compliance attributes, and determine the strategy version number and compliance threshold; send the strategy commitment value, strategy version number, and compliance threshold to the device to be audited; generate challenge parameters containing a one-time random number, session identifier, and verifier identifier, and send the challenge parameters and the disclosure level indicated in the audit request to the device to be audited; and verification module 201 is also used to verify the validity of the digital signature and zero-knowledge proof returned by the proof module and output the audit result. The measurement module 202 is used to obtain the startup chain digest and current system configuration information in the trusted execution environment, normalize and encode the current system configuration information to obtain the configuration code, generate a measurement vector based on the startup chain digest, configuration code and current measurement time, generate a public commitment value based on the measurement vector, generate a binding message digest based on the public commitment value, challenge parameters and policy version number, and sign the binding message digest using the device proof key to obtain a digital signature; the measurement module is also used to send the configuration code to the witness generation entity, so that the witness generation entity can generate the corresponding member witness certificate according to the configuration code and policy version number, and distribute the member witness certificate to the device to be audited; The proof module 203 is used to generate a zero-knowledge proof based on the measurement vector, member witness proof, digital signature, public commitment value, and policy commitment value within a protected isolated space, and return the digital signature and zero-knowledge proof to the verification module. The zero-knowledge proof is used to prove that: the measurement vector and the public commitment value satisfy the commitment relationship, each configuration code in the measurement vector belongs to the set of compliance attributes after normalization of the policy commitment value, and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold.

[0068] Based on the above settings, the audit steps, including policy commitment generation and distribution, dynamic challenge binding, trusted execution environment measurement and signing, zero-knowledge compliance proof generation, verification of signatures and zero-knowledge proofs, and output of audit results, utilize policy commitment values ​​and member witness proofs to ensure that rules are not leaked and that devices have proof capabilities. The binding of challenge parameters and signatures ensures the real-time nature and unforgeability of sessions. Trusted measurement ensures the authenticity of input states. Zero-knowledge proofs generated in a protected isolated space ensure the verifiability of compliance conclusions without leaking privacy. The introduction of disclosure-level instructions ensures the minimization of output results. This enables the proof that the current true state of the device meets the domestic IT innovation compliance policy (including multi-dimensional set membership relationships and threshold compliance) without exposing the complete plaintext configuration of the device to the verifier. It also supports outputting the minimum necessary audit results according to the disclosure level. Furthermore, the binding of challenge parameters and signatures effectively prevents replay and cross-session reuse attacks, achieving the technical effects of avoiding device privacy leaks, improving the authenticity and reliability of audit results, and providing flexible disclosure granularity control.

[0069] Meanwhile, since this application is based on the aforementioned IT innovation compliance audit system 200 to implement any of the aforementioned IT innovation compliance audit methods, the execution operations corresponding to the individual execution of each module in the aforementioned IT innovation compliance audit system or the interaction between each module are consistent with those in the aforementioned IT innovation compliance audit methods, and can achieve all the beneficial effects corresponding to the aforementioned IT innovation compliance audit methods. This application will not elaborate further here.

[0070] It should be noted that the specific modules within the aforementioned domestic IT compliance audit system are defined primarily based on the corresponding operations performed and are not intended to limit the specific modules. For example, a policy compilation module can be introduced into the domestic IT compliance audit system to decompose domestic IT compliance policies into at least one set of compliance attributes, perform standardized encoding on the compliance attribute sets, generate policy commitment values ​​based on the standardized encoded compliance attribute sets, and determine the policy version number, compliance threshold, and member witness verification steps. Third-party licensing tools can also be introduced into the identity authentication system for key management, such as generating device verification keys and distributing device verification keys.

[0071] According to a specific implementation method of the present invention, such as Figure 3 and Figure 4 As shown, the domestic IT innovation audit and compliance system may include an audit / verification module (also known as the audit / verification module, which performs audit and verification functions) deployed on the server side, a policy compilation module, and an accountability module (not shown in the diagram); and a measurement module and a verification module deployed on the device to be audited. Specifically, the interaction process between modules mainly includes: Figure 3 It is shown that: (1) Strategy compilation steps When the auditor receives an audit request for the device to be audited, it first determines the domestic IT innovation compliance strategy corresponding to this audit, and then breaks down the domestic IT innovation compliance strategy into a set of compliance attributes in four dimensions: OS, CPU, DB, and MW. The set of compliance attributes {OS set, CPU set, DB set, MW set} is then sent to the strategy compilation module. The policy compilation module performs normalized encoding on the set of compliance attributes (preferably by constructing a commitment tree using SM3 during normalized encoding), generates policy commitment values ​​{C_OS, C_CPU, C_DB, C_MW}, and returns them to the auditor; The auditor generates set weight values ​​a, b, c, d corresponding to each set of compliance attributes (constructing a weight vector w=(a,b,c,d)) and a compliance threshold T; (2) Challenge Issuance Steps The auditor generates challenge parameters for the current audit task, including a one-time random number (nonce), a session identifier (session_id), and a verifier identifier (verifier_id). The challenge parameters, along with the disclosure level (disclose_level) indicated in the audit request and the policy version number (policy_version), are sent to the device. The nonce is used to prevent old proofs from being replayed, the session_id is used to bind to the current session, and the verifier_id is used to restrict the proof to be valid only for the current verifier.

[0072] (3) Reliable measurement steps The measurement module deployed in the device to be audited obtains the boot chain digest boot_digest from TPM, TEE, DICE, or trusted boot chain, and performs normalized encoding on the local operating system, CPU, database, and middleware to obtain code_os, code_cpu, code_db, and code_mw. These are combined with the current measurement timestamp ts_local to form the measurement vector M. The measurement vector M and the commitment random number r are calculated using the cryptographic commitment algorithm Com (the commitment algorithm can be based on a hash tree, vector commitment, or other commitment mechanism suitable for verification by the proof system) to obtain the public commitment value commit_M = Com(M; r).

[0073] Specifically, after the device under audit performs standardized encoding on its local operating system, CPU, database, and middleware to obtain code_os, code_cpu, code_db, and code_mw, it sends the configuration encoding (code_os, code_cpu, code_db, code_mw) to the policy compilation module. This allows the policy compilation module to further generate corresponding member witness certificates (w_os, w_cpu, w_db, w_mw) for the configuration encoding to be proved, and then distribute them to the device under audit through a secure channel.

[0074] (4) Challenge Binding Steps The measurement module uses SM3 to combine and digest commit_M, nonce, session_id, verifier_id, and policy_version to obtain the binding message digest msg; then, it uses the proof key AK to sign msg via SM2 to obtain the digital signature sigma; this step is used to prove that "subsequent proof materials do indeed correspond to the current device, the current measurement value, and the current session".

[0075] (5) Steps for generating pseudo-anonymity Based on actual needs, the device to be audited can calculate a pseudo-anonym identifier based on the device secret (device_secret), audit period (audit_epoch), permission salt (authority_salt), and policy version (policy_version). This identifier replaces the real identity during the normal audit phase to reduce the risk of long-term association.

[0076] Figure 4 It is shown that: (6) Zero-knowledge proof generation steps The proof module uses M, sigma, w_os, w_cpu, w_db, and w_mw as private inputs and C_OS, C_CPU, C_DB, C_MW, a, b, c, d, T, commit_M, nonce, session_id, verifier_id, and policy_version as public inputs to generate a zero-knowledge proof pi. The core of this zero-knowledge proof is that the encoding corresponding to the current state of the device satisfies a four-dimensional set relationship, and the overall score is not lower than the compliance threshold T.

[0077] (7) Proof Submission Steps The device to be audited submits {pseudonym, sigma, commit_M, pi, disclose_level, policy_version} to the verification party, where disclose_level is used to indicate the granularity of the output results allowed for this audit.

[0078] (8) Joint verification steps The verifier first verifies whether the digital signature sigma is a valid SM2 signature generated around this message; Then verify whether the zero-knowledge proof pi holds true; Only when both types of verifications are passed is the audited device considered to have completed the compliance proof under the real-state binding.

[0079] (9) Token issuance steps Upon successful verification, the verifier generates a compliance token, which may include the audit result (result), policy version number (policy_version), disclosure level (disclose_level), token expiry date (expiry), pseudo-anonym identifier (pseudonym), and verifier signature (sig_V). This token can then be used by access control, rectification acceptance, or ongoing monitoring systems.

[0080] (10) Failure return steps If any step of the verification fails, a rejection message is returned, which includes the reason_code, session_id, and policy_version for subsequent tracking, review, and error classification.

[0081] (11) Authorization and accountability steps (not shown in the figure) If any disputes or regulatory requirements arise later, the verifier can submit {pseudonym, token, authorization_proof} to the accountability module. Provided that the authorization conditions are met, the accountability module will return the real device identifier or internal mapping result based on the pseudo-anonymous identifier.

[0082] It is understood that, based on the specific implementation methods described above, the embodiments of the present invention achieve at least the following technical effects: Reduced risk of sensitive information exposure: Auditors do not need to obtain the complete plaintext device configuration; Improved audit authenticity: Compliance conclusions are bound to trusted measurement results, challenge parameters, and device signatures; Support for minimum necessary disclosure: Only the minimum necessary conclusions can be output as needed; Enhanced resistance to replay and forgery: Constrained by nonce, session_id, verifier_id, and device signature; Balanced privacy and accountability: Pseudo-anonymity is used in the regular phase, and the authorized scenario supports restoring the real identity; Adaptable to the domestic IT innovation environment: Can be deployed in conjunction with the national cryptographic algorithm system and domestic trusted execution environment; Facilitates the formation of a unified audit platform: Can be combined with traditional scanning links to form a unified audit system of "cryptographic proof level" and "scan inference level".

[0083] The present invention also provides a non-transitory machine-readable medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of the present invention.

[0084] This invention also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform the methods of embodiments of this invention. The computer program product should be understood as a software product that primarily implements the methods of this invention through a computer program.

[0085] This invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method of this invention.

[0086] refer to Figure 5 The present invention will now be described in the form of a structural block diagram of an electronic device that can serve as an embodiment of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0087] like Figure 5As shown, the electronic device includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 may also store various programs and data required for the operation of the electronic device. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0088] Multiple components in the electronic device are connected to I / O interface 505, including: input unit 506, output unit 507, storage unit 508, and communication unit 509. Input unit 506 can be any type of device capable of inputting information into the electronic device. Input unit 506 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 507 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 508 may include, but is not limited to, disks and optical discs. Communication unit 509 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, and / or wireless communication transceivers, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0089] The computing unit 501 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing units, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above. For example, in some embodiments, the method embodiments of the present invention can be implemented as a computer program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 502 and / or communication unit 509. In some embodiments, the computing unit 501 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0090] Computer programs for implementing the methods of embodiments of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0091] In the context of embodiments of the present invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable signal medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, or infrared systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0092] It should be noted that the term "comprising" and its variations used in the embodiments of the present invention are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The modifications of "one" and "multiple" mentioned in the embodiments of the present invention are illustrative and not restrictive. Those skilled in the art should understand that, unless explicitly indicated otherwise in the context, they should be understood as "one or more".

[0093] The information / data involved in the embodiments of this invention (including but not limited to user device information / data, user personal information / data, information / data used for analysis, stored information / data, displayed information / data, etc.) are all information / data that has been permitted by the user or fully agreed upon by all parties. Furthermore, the collection, use and processing of such information / data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to agree or refuse.

[0094] The steps described in the method embodiments provided by this invention can be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of protection of this invention is not limited in this respect.

[0095] The term "embodiment" in this specification refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of the invention. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply independence or alternativeity from other embodiments. The various embodiments in this specification are described in a related manner, with reference to each other for similar or identical parts. In particular, for apparatus, device, and system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, and relevant details are referred to in the description of the method embodiments.

[0096] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A method for auditing compliance with information technology innovation standards, characterized in that, The method is applied to a domestic IT innovation compliance audit system, which includes a verification module deployed on the server side, a measurement module deployed on the device to be audited, and a verification module; the method includes: In response to receiving an audit request for the device to be audited, the verification module decomposes the domestic IT compliance strategy into at least one set of compliance attributes according to the audit request, performs normalized encoding on the set of compliance attributes, generates a strategy commitment value based on the normalized encoded set of compliance attributes, and determines the strategy version number and compliance threshold; the strategy commitment value, the strategy version number, and the compliance threshold are then sent to the device to be audited. The verification module generates challenge parameters containing a one-time random number, a session identifier, and a verifier identifier, and sends the challenge parameters and the disclosure level indicated in the audit request to the device to be audited. The measurement module acquires the startup chain digest and current system configuration information in the trusted execution environment. It then normalizes and encodes the current system configuration information to obtain a configuration code. A measurement vector is generated based on the startup chain digest, the configuration code, and the current measurement time. A public commitment value is generated based on the measurement vector. A binding message digest is generated based on the public commitment value, the challenge parameter, and the policy version number. This binding message digest is then signed using a device proof key to obtain a digital signature. The measurement module sends the configuration code to the witness generation entity, enabling the witness generation entity to generate a corresponding member witness certificate based on the configuration code and the policy version number, and then distributes the member witness certificate to the device to be audited. The proof module generates a zero-knowledge proof within a protected, isolated space based on the measurement vector, the member witness proof, the digital signature, the public commitment value, and the policy commitment value, and returns the digital signature, the public commitment value, and the zero-knowledge proof to the verification module. The zero-knowledge proof proves that: the measurement vector and the public commitment value satisfy a commitment relationship; each configuration code in the measurement vector belongs to the set of compliance attributes after normalization of the policy commitment value; and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold. The verification module verifies the validity of the digital signature and the zero-knowledge proof, and outputs the audit results.

2. The method according to claim 1, characterized in that, The compliance attribute set includes one or more of the following: operating system set, central processing unit set, database set, and middleware set; the configuration code corresponds to the compliance attribute set and includes one or more of the following: operating system code, central processing unit code, database code, and middleware code. The policy commitment value is generated based on a cryptographic commitment structure, which includes a Merkle tree, a cryptographic accumulator, or a vector commitment.

3. The method according to claim 1, characterized in that, The calculation steps for the compliance score include: generating set weight values ​​corresponding to each compliance attribute set through the verification module, constructing a weight vector, and sending the weight vector, along with the policy commitment value, the policy version number, and the compliance threshold, to the device to be audited; the verification module deployed on the device to be audited generates a Boolean compliance vector based on the membership verification results of each configuration code in the measurement vector for the compliance attribute set, calculates the inner product of the Boolean compliance vector and the weight vector, and obtains the compliance score; The steps to prove that the compliance score is not lower than the compliance threshold include: using a zero-knowledge range proof algorithm to prove that the compliance score falls within a preset compliance range; wherein, the lower limit of the preset compliance range is the compliance threshold, and the upper limit of the range is the theoretical maximum compliance score.

4. The method according to claim 1, characterized in that, The device to be audited uses the SM4 algorithm to symmetrically encrypt and store the intermediate states of the member witness proof, commitment random number, and zero-knowledge proof. The communication session between the device to be audited and the verification module is encrypted using the SM4 algorithm.

5. The method according to claim 1, characterized in that, The method further includes: If the verification passes, a compliance token is generated by the verification module and sent to the device to be audited; wherein, the compliance token includes the audit result, policy version number, token validity period and verification party signature.

6. The method according to claim 1, characterized in that, The measurement module or the proof module controls the disclosure granularity of the audit results through the public output of the zero-knowledge proof based on the received disclosure level; the disclosure granularity includes at least one of pass / fail, compliance dimension information, non-compliance dimension information, or compliance score achievement status.

7. The method according to claim 1, characterized in that, The domestic IT innovation compliance audit system also includes an accountability module, and the method further includes: The measurement module generates a pseudo-anonymous identifier for the device to be audited based on the device secret, audit cycle, and policy version number; wherein, the device secret is pre-installed on the device to be audited, and the audit cycle is pre-issued by the verification module or predefined by the system; When sending the digital signature, the public commitment value, and the zero-knowledge proof to the verification module, the pseudo-anonymous identifier is also sent as the identity identifier of the device to be audited. The accountability module establishes an authorization and accountability mechanism based on the SM9 cryptographic algorithm. When the regulatory authorization conditions are met, the accountability module performs the mapping of the pseudo-anonymous identifier back to the real device identifier of the device to be audited.

8. The method according to claim 1, characterized in that, The steps of generating a public commitment value based on the measurement vector, generating a binding message digest based on the public commitment value, the challenge parameter, and the policy version number, and signing the binding message digest using a device proof key to obtain a digital signature include: The public commitment value is obtained by calculating the measurement vector and the commitment random number using a cryptographic commitment algorithm; The SM3 algorithm is used to hash the public commitment value, the challenge parameter, and the policy version number to obtain the binding message digest. The digital signature is obtained by signing the binding message digest using the SM2 algorithm.

9. A domestic IT compliance audit system, characterized in that, This includes a verification module deployed on the server side, a measurement module deployed on the device to be audited, and a verification module; among which, The verification module is configured to, in response to receiving an audit request for the device to be audited, decompose the domestic IT compliance strategy into at least one set of compliance attributes according to the audit request, perform normalized encoding on the set of compliance attributes, generate a strategy commitment value based on the normalized encoded set of compliance attributes, and determine the strategy version number and compliance threshold; send the strategy commitment value, the strategy version number, and the compliance threshold to the device to be audited; generate challenge parameters including a one-time random number, a session identifier, and a verifier identifier, and send the challenge parameters and the disclosure level indicated in the audit request to the device to be audited. The measurement module is used to obtain the startup chain digest and current system configuration information in a trusted execution environment; to normalize and encode the current system configuration information to obtain a configuration code; to generate a measurement vector based on the startup chain digest, the configuration code, and the current measurement time; to generate a public commitment value based on the measurement vector; to generate a binding message digest based on the public commitment value, the challenge parameter, and the policy version number; and to sign the binding message digest using a device proof key to obtain a digital signature. The measurement module is also used to send the configuration code to a witness generation entity, so that the witness generation entity generates a corresponding member witness certificate based on the configuration code and the policy version number, and distributes the member witness certificate to the device to be audited. The proof module is used to generate a zero-knowledge proof based on the measurement vector, the member witness proof, the digital signature, the public commitment value, and the policy commitment value within a protected isolated space, and to return the digital signature, the public commitment value, and the zero-knowledge proof to the verification module; wherein, the zero-knowledge proof is used to prove that: the measurement vector and the public commitment value satisfy a commitment relationship, each configuration code in the measurement vector belongs to the set of compliance attributes after normalization of the policy commitment value, and the compliance score calculated based on the compliance status of each configuration code is not lower than the compliance threshold; The verification module is also used to verify the validity of the digital signature and the zero-knowledge proof returned by the proof module, and output the audit results.

10. A non-transitory machine-readable medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to claims 1 to 8.

Images