Medical health code generation method and verification method

Abstract

The invention relates to the technical field of medical health data processing, and provides a generation method and a verification method of a medical health code. The method comprises the following steps: constructing a trusted secure computing environment, wherein the trusted secure computing environment comprises a virtual machine memory encryption capability and an endogenous password service capability; in the trusted secure computing environment, performing data preprocessing and data extraction on the initial identity information of the first user based on the memory encryption capability of the virtual machine to obtain health code generation factor data; and in the trusted secure computing environment, performing code conversion processing on the health code generation factor data based on the endogenous password service capability to obtain first basic code data, and performing dynamic mask processing, dynamic encryption processing and signature protection processing based on the first basic code data to generate a first medical health code of the first user. Based on the scheme of the invention, the information security of the generation and verification process of the medical health code can be improved.

Description

Technical Field

[0001] This invention relates to the field of medical and health data processing technology, and in particular to a method for generating and verifying a medical health code. Background Technology

[0002] In the field of medical and health data processing technology, to achieve interoperability of electronic health records and mutual recognition of examination and test results across institutions and regions, a unified identity identification mechanism is needed to connect scattered medical data, with the medical health code being one possible implementation. However, the generation and verification process of medical health codes lacks information protection, potentially leading to information leaks. Therefore, improving the information security of the generation and verification process of medical health codes has become an urgent technical problem to be solved. Summary of the Invention

[0003] This application provides a method for generating and verifying a medical health code, which addresses the technical problem of improving the information security of the generation and verification process of the medical health code.

[0004] In a first aspect, embodiments of this application provide a method for generating a medical health code, comprising: Build a trusted and secure computing environment, which includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities; In a trusted and secure computing environment, the initial identity information of the first user is preprocessed and extracted based on the virtual machine memory encryption capability to obtain health code generation factor data. In a trusted and secure computing environment, the health code generation factor data is encoded and converted based on the endogenous cryptographic service capability to obtain the first basic code data. Based on the first basic code data, dynamic masking, dynamic encryption and signature protection are performed to generate the first user's first medical health code.

[0005] Secondly, embodiments of this application provide a method for verifying a medical health code, including: Receive the second user's second medical health code; The second medical health code is transmitted to the trusted and secure computing environment of the first party. The trusted and secure computing environment includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. In a trusted and secure computing environment, the second medical health code is signed, verified, and decrypted based on the endogenous cryptographic service capability to obtain the second basic code data. Then, the second basic code data is demasked and decoded to obtain the second identity information. The identity validity is verified based on the second identity information, and the verification result is obtained.

[0006] The method for generating and verifying a medical health code provided in this application first constructs a trusted and secure computing environment that includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. Within this environment, the initial identity information of the first user is preprocessed and extracted based on the virtual machine memory encryption capabilities to obtain health code generation factor data. Then, the health code generation factor data is encoded and converted based on the intrinsic cryptographic service capabilities to obtain first basic code data. Finally, dynamic masking, dynamic encryption, and signature protection are performed on the first basic code data to generate the first user's first medical health code. Thus, through the hardware-level isolation protection provided by the trusted and secure computing environment, the entire process of processing the first user's initial identity information is placed under the dual protection of virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. This ensures that sensitive information is encrypted and the plaintext key does not appear in system memory. Based on this, a multi-layered protection mechanism is constructed by comprehensively utilizing data preprocessing and extraction for desensitization, encoding and conversion for standardization, dynamic masking, dynamic encryption, and signature protection. Finally, a unique and unforgeable first medical health code is generated, achieving isolation of sensitive information and effectively improving the information security of the medical health code generation process. The verification process for medical health codes is also conducted in a trusted and secure computing environment. For similar reasons, this also effectively improves the information security of the verification process for medical health codes. Attached Figure Description

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

[0008] Figure 1 This is a flowchart illustrating the method for generating a medical health code provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the process of building and managing a secure virtual machine provided in this application embodiment; Figure 3 This is a schematic diagram of the interaction architecture between the startup process and the trusted platform module provided in the embodiments of this application; Figure 4 This is a schematic diagram of the software and hardware hierarchy and component interactions of cryptographic operations provided in the embodiments of this application; Figure 5 This is a schematic diagram of the hierarchical distribution and core module composition of the health code encryption algorithm technology provided in this application embodiment; Figure 6This is a schematic diagram of the hierarchical processing of identity identifiers and component interactions in the generation of medical health codes provided in this application embodiment; Figure 7 This is a flowchart illustrating the medical health code verification method provided in this application embodiment; Figure 8 This is a schematic diagram of the interactive architecture of cross-level institutional verification and on-chain evidence storage of medical health codes provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hierarchical distribution and interaction logic of the medical health code full-process architecture provided in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0010] In the field of medical and health data processing technology, in order to achieve interoperability of electronic health records and mutual recognition of examination and test results across institutions and regions, a unified identity identification mechanism needs to be established to connect scattered medical data, among which the medical health code is a possible implementation form.

[0011] In related technologies, the process of generating and verifying medical health codes lacks information protection, potentially leading to information leakage. For example, the generation process of medical health codes in these technologies directly uses the user's relevant identification number as basic data, storing and processing it in plaintext in memory, making it vulnerable to memory data leakage risks caused by malware or physical attacks. It is evident that the aforementioned technologies have shortcomings: during the health code generation and verification process, sensitive information such as the user's relevant identification number is stored in plaintext in memory, lacking an effective memory data protection mechanism, making it prone to information leakage; simultaneously, traditional cryptographic operations rely on external cryptographic hardware and require information transmission over a network, easily becoming a performance bottleneck and security risk point; furthermore, using the user's relevant identification number as the unique identifier of the health code cannot effectively protect user privacy.

[0012] Therefore, improving the information security of the generation and verification process of medical health codes has become an urgent technical problem to be solved.

[0013] To address the aforementioned issues, the main solution provided in this application includes: First, constructing a trusted and secure computing environment that incorporates virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. Within this environment, the initial identity information of the first user is preprocessed and extracted based on the virtual machine memory encryption capabilities to obtain health code generation factor data. Then, the health code generation factor data is encoded and converted based on the intrinsic cryptographic service capabilities to obtain first basic code data. Finally, dynamic masking, dynamic encryption, and signature protection are performed on the first basic code data to generate the first user's first medical health code. Thus, through the hardware-level isolation protection provided by the trusted and secure computing environment, the entire process of processing the first user's initial identity information is placed under the dual protection of virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. This ensures that sensitive information is encrypted and the plaintext key does not appear in system memory. Furthermore, by comprehensively utilizing data preprocessing and extraction for desensitization, encoding and conversion for standardization, dynamic masking, dynamic encryption, and signature protection, a multi-layered protection mechanism is constructed. Ultimately, a unique and unforgeable first medical health code is generated, achieving isolation of sensitive information and effectively improving the information security of the medical health code generation process. The verification process for medical health codes is also conducted in a trusted and secure computing environment. For similar reasons, this also effectively improves the information security of the verification process for medical health codes.

[0014] Explanation of some terms used in the embodiments of this application: Trusted Platform Module (TPM): A hardware module used for secure storage and encrypted computing, providing functions such as data sealing and key management.

[0015] Platform Configuration Register (PCR): A register in the Trusted Platform Module used to store integrity measurements at various stages of the system startup process.

[0016] Virtual Machine Memory Encryption: The ability to transparently encrypt the memory of a virtual machine system through the processor's built-in memory encryption engine.

[0017] Intrinsic Cryptographic Services: Provides cryptographic computation and key management capabilities by utilizing the CPU's built-in cryptographic coprocessor and secure storage module.

[0018] Confidential Secure Virtualization (CSV): A secure virtual machine with independent caching and translational backup buffer resources, and hardware-level isolation from the host and other virtual machines.

[0019] Cryptographic Co-Processor (CCP): A hardware unit built into the CPU dedicated to performing cryptographic algorithm operations, providing services for Chinese cryptographic algorithms such as SM2, SM3, and SM4.

[0020] Cryptographic Instruction Set (CIS): An instruction set module inside the CPU used to support efficient operation of cryptographic algorithms.

[0021] Security Development Framework Extension Interface (SDF): A software interface that conforms to national cryptographic standards and specifications, used by upper-layer applications to call underlying cryptographic hardware services.

[0022] Hash-based Message Authentication Code (HMAC): A message authentication code based on a cryptographic hash algorithm and key calculation, used for data integrity verification.

[0023] SM2 Algorithm (SM2): A nationally certified asymmetric encryption algorithm based on elliptic curves.

[0024] SM3 Algorithm (SM3): A cryptographic hash algorithm certified by the Chinese national cryptographic standard.

[0025] SM4 Algorithm (Shang Mi 4 Algorithm): A nationally certified block cipher symmetric encryption algorithm.

[0026] Cipher Block Chaining (CBC): A block cipher mode in which each plaintext block is first XORed with the previous ciphertext block before being encrypted.

[0027] Public Key Cryptography Standards #7 (PKCS7): A padding standard for padding data to the block length required by block cipher algorithms.

[0028] Unicode Transformation Format-8 (UTF-8): A variable-length Unicode character encoding format that uses 1 to 4 bytes to represent a character.

[0029] Basic Input / Output System (BIOS): Firmware that runs when the computer starts up, responsible for hardware initialization and boot loading.

[0030] Grub (Grand Unified Bootloader): A multi-operating system bootloader used to load the operating system kernel.

[0031] Operating System (OS): The core system software that manages computer hardware and software resources.

[0032] Central Processing Unit (CPU): The core processing unit of a computer, which executes instructions and performs calculations.

[0033] Trusted Key Management (TKM): Key management operations that support cryptographic services, typically working in conjunction with the platform's security processor.

[0034] Platform Security Processor (PSP): A hardware security module that provides secure storage and cryptographic operations.

[0035] Software Development Kit (SDK): A collection of application programming interfaces provided by blockchain nodes for calling smart contract functions.

[0036] The following will provide a detailed description of the methods for generating and verifying medical health codes provided in the embodiments of this application.

[0037] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for generating a medical health code, as provided in an embodiment of this application. Figure 1 As shown, the method in this application embodiment may include the following steps S101-S103.

[0038] S101, Build a trusted and secure computing environment, which includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities.

[0039] Specifically, to provide hardware-level data isolation and cryptographic security, a trusted secure computing environment (TCI) needs to be built. The TCI includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. The TCI refers to a computing execution environment built through hardware-level isolation and cryptographic protection mechanisms. This environment ensures the confidentiality and integrity of data processing, such as a secure execution domain created based on a processor supporting confidential computing. Virtual machine memory encryption capabilities refer to the processor's built-in memory encryption engine's ability to transparently encrypt the virtual machine system memory. This capability ensures that data in memory is stored in ciphertext and the key is securely managed by the processor. Intrinsic cryptographic service capabilities refer to the CPU's built-in cryptographic coprocessor and secure storage module, providing cryptographic computation and key management capabilities. This capability ensures that cryptographic computations are performed internally on the chip and that the plaintext key does not appear in system memory.

[0040] Regarding this step, some possible implementations include configuring virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. Based on these capabilities, a trusted and secure computing environment is constructed. The configuration process for virtual machine memory encryption capabilities includes performing virtual machine creation operations, generating memory encryption keys, encrypting system memory pages in real time, and managing the memory encryption keys through a trusted key management module. The configuration process for intrinsic cryptographic service capabilities includes deploying a trusted platform module, sealing user keys within the trusted platform module using a data sealing function, providing cryptographic computation services through the CPU's built-in cryptographic coprocessor, and providing an SDF extension interface to call the cryptographic coprocessor to perform cryptographic computations. In some possible implementations, based on the first user's business needs and security level requirements, a target security policy can be selected from a preset set of security policies. The memory encryption range in the virtual machine memory encryption capabilities and the cryptographic algorithm combinations in the intrinsic cryptographic service capabilities can be configured according to the target security policy. The configured virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities can then be activated to construct a trusted and secure computing environment that conforms to the target security policy.

[0041] S102, in a trusted and secure computing environment, the initial identity information of the first user is preprocessed and extracted based on the virtual machine memory encryption capability to obtain health code generation factor data.

[0042] Specifically, in order to convert the initial identity information of the first user into a standardized data format that conforms to the health code generation rules, it is necessary to perform data preprocessing and data extraction on the initial identity information of the first user in a trusted and secure computing environment, based on the virtual machine memory encryption capability, to obtain health code generation factor data. Here, the first user refers to the natural person subject who needs to generate a medical health code; the initial identity information of the first user refers to the original identity data set containing document type code, document number, name, regional factor, and reserved control factor; data preprocessing refers to the process of cleaning, format unifying, and standardizing the initial identity information; data extraction refers to the data filtering process of extracting specified content from the preprocessed identity information according to predetermined rules; and health code generation factor data refers to the standardized data set obtained after data preprocessing and data extraction, used for subsequent encoding conversion processing.

[0043] Regarding this step, in some possible implementations, in a trusted and secure computing environment, based on the virtual machine memory encryption capability, the data standardization processing of the document type code, document number, name, regional factor, and reserved control factor in the initial identity information of the first user is performed to obtain standardized identity information; the standardized identity information is then converted according to the UTF-8 encoding format to obtain a UTF-8 encoded string; and a specified number of bytes are extracted from the UTF-8 encoded string as health code generation factor data. In some possible implementations, a trusted and secure computing environment can be used to perform data integrity verification on the initial identity information of the first user, based on the virtual machine's memory encryption capabilities. After successful verification, the document type code, document number, name, regional factor, and reserved control factor are concatenated in a predetermined order to obtain concatenated identity information. Sensitive information desensitization processing is then performed on the concatenated identity information, and the desensitized concatenated identity information is used as standardized identity information. The standardized identity information is then converted into a UTF-8 encoded string according to the UTF-8 encoding format. A specified number of bytes that meet the length requirements of the health code generation factor data are extracted from the UTF-8 encoded string, and this specified number of bytes is used as the health code generation factor data.

[0044] S103, in a trusted and secure computing environment, the health code generation factor data is encoded and converted based on the endogenous cryptographic service capability to obtain the first basic code data, and dynamic masking, dynamic encryption and signature protection processing are performed on the first basic code data to generate the first user's first medical health code.

[0045] Specifically, to construct a multi-layered security protection mechanism and generate a unique and unforgeable medical health code, it is necessary to perform encoding conversion processing on the health code generation factor data in a trusted secure computing environment based on the inherent cryptographic service capability to obtain the first basic code data. Then, dynamic masking, dynamic encryption, and signature protection processing are performed on the first basic code data to generate the first user's first medical health code. Here, encoding conversion processing refers to the data processing process of converting the health code generation factor data into a standard character encoding format; the first basic code data refers to the basic data set containing the original data string and checksum obtained after encoding conversion processing; dynamic masking processing refers to the data protection process of performing HMAC calculation on the first basic code data based on a dynamic key; dynamic encryption processing refers to the data protection process of grouping and encrypting intermediate concatenated data based on dynamic parameters; signature protection processing refers to the identity authentication process of signing the medical identity identifier using a digital signature algorithm; and the first medical health code refers to the final identity identifier code with multiple security protections generated after dynamic masking, dynamic encryption, and signature protection processing.

[0046] Regarding this step, in some possible implementations, in a trusted and secure computing environment, the document type code, document number, and name in the health code generation factor data can be converted and concatenated using character encoding to obtain the original data string; a first checksum is determined based on the original data string and concatenated to the end of the original data string to obtain the first basic code data; a corresponding random number is selected from a preset mask library based on the first checksum as the HMAC key; based on the intrinsic cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the first basic code data and the HMAC key to obtain the protected identity code; the protected identity code is concatenated with the first organization identifier corresponding to the first user to obtain the first intermediate concatenated data; and a dynamic identifier is generated based on the first checksum. The process involves: selecting an initial vector from a mask library based on a dynamic identifier; invoking the SM4 algorithm based on the endogenous cryptography service capability, encrypting the first intermediate concatenated data using CBC mode, the group key corresponding to the first institution identifier, and the initial vector to obtain the first encrypted data; concatenating the first encrypted data with the dynamic identifier to obtain the first medical identity identifier; invoking the SM2 algorithm based on the endogenous cryptography service capability, digitally signing the first medical identity identifier using the platform key corresponding to the first institution identifier to obtain the first signature value; binding the first medical identity identifier, the first signature value, and the medical health code generation request digest execution spatiotemporal information of the first user based on a blockchain smart contract to generate the first encrypted identity credential; and generating the first user's first medical health code based on the first encrypted identity credential.In some possible implementations, within a trusted secure computing environment, the health code generation factor data is input to a cryptographic coprocessor via an SDF extension interface based on intrinsic cryptographic service capabilities. Inside the cryptographic coprocessor, a security processor and a key coprocessor perform encoding conversion processing on the health code generation factor data, converting the document type code, document number, and name into a standard encoding format and concatenating them to obtain the original data string. The cryptographic coprocessor then calculates a first checksum based on the original data string, concatenating the first checksum with the original data string to form the first basic code data. Based on the first checksum, a corresponding random number is selected from a preset mask library as the HMAC key. The cryptographic coprocessor then calls the SM3 algorithm to perform HMAC-SM3 calculation on the first basic code data and the HMAC key to obtain the protected identity code. Finally, the protected identity code is combined with the first institution identifier... The cryptographic coprocessor internally concatenates the data to obtain the first intermediate concatenated data; it generates a dynamic identifier based on the first checksum, and selects an initial vector from the mask library based on the dynamic identifier; it calls the SM4 algorithm through the cryptographic coprocessor, and performs encryption operations on the first intermediate concatenated data using CBC mode, the group key corresponding to the first organization identifier, and the initial vector to obtain the first encrypted data; it concatenates the first encrypted data with the dynamic identifier to form the first medical identity identifier; it calls the SM2 algorithm through the cryptographic coprocessor, and performs digital signature operations on the first medical identity identifier using the platform key corresponding to the first organization identifier to obtain the first signature value; it binds the first medical identity identifier, the first signature value, and the first user's medical health code generation request digest to spatiotemporal information through a blockchain smart contract to generate the first encrypted identity credential; and it outputs the first encrypted identity credential as the first user's first medical health code.

[0047] In this embodiment, the hardware-level isolation protection provided by the trusted secure computing environment places the entire processing of the first user's initial identity information under the dual protection of virtual machine memory encryption and intrinsic cryptographic service capabilities. This ensures that sensitive information is encrypted and the plaintext key does not appear in system memory. Based on this, a multi-layered protection mechanism is constructed by comprehensively utilizing data preprocessing and extraction for desensitization, encoding conversion for standardization, dynamic masking, dynamic encryption, and signature protection. Ultimately, a unique and unforgeable first medical health code is generated, achieving isolation of sensitive information and effectively improving the information security of the medical health code generation process. The verification process of the medical health code is also performed in the trusted secure computing environment, and for similar reasons, it also effectively improves the information security of the verification process.

[0048] In one embodiment, the step of "building a trusted and secure computing environment" described above can be further refined and may include the following steps: Configure virtual machine memory encryption capabilities and configure built-in cryptographic service capabilities; Building a trusted and secure computing environment based on virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities; The configuration process for virtual machine memory encryption includes: creating a secure virtual machine with independent cache and translation fallback buffer resources, isolated from the host and other virtual machines; generating a memory encryption key through the processor, and encrypting the system memory pages of the secure virtual machine in real time based on the memory encryption key, so that plaintext data written to memory is encrypted and stored, and ciphertext data read from memory is decrypted in real time; and managing the memory encryption key through a trusted key management module to ensure that the plaintext of the memory encryption key does not appear in the system memory. The configuration process for intrinsic cryptographic service capabilities includes: deploying a trusted platform module in a secure virtual machine; sealing the user key within the trusted platform module using its data sealing function; setting the expected value and authorization code for the platform configuration register; providing cryptographic computation services through the CPU's built-in cryptographic coprocessor, including at least one of the SM2, SM3, SM4 algorithms and a true random number generator; and providing an SDF extension interface through the business interface, which is used to call the cryptographic coprocessor to perform cryptographic computations.

[0049] Specifically, in order to build a hardware-isolated execution environment, prevent the host and other virtual machines from illegally accessing memory data, and ensure the confidentiality of data during processing, it is necessary to configure virtual machine memory encryption capabilities.

[0050] Regarding this step, in some possible implementations, a secure virtual machine can be created. The secure virtual machine has independent cache and translation fallback buffer resources and is isolated from the host and other virtual machines. A memory encryption key is generated by the processor, and the system memory pages of the secure virtual machine are encrypted in real time based on the memory encryption key. This ensures that plaintext data written to memory is stored in encrypted form, and ciphertext data read from memory is decrypted in real time. The memory encryption key is managed by a trusted key management module to ensure that the plaintext of the memory encryption key does not appear in the system memory.

[0051] More specifically, the detailed process of configuring virtual machine memory encryption capabilities includes: First, a secure virtual machine is started and configured through the virtual machine manager. This secure virtual machine is allocated independent caches and translation fallback buffers upon creation, ensuring its runtime environment is hardware-isolated from the host operating system and other virtual machines, preventing side-channel attacks and data leaks. Then, the processor's built-in memory encryption function is activated. The processor generates one or more memory encryption keys when the secure virtual machine starts. These keys are accessible only within the processor and cannot be read by the operating system or the virtual machine manager. During the operation of the secure virtual machine, the processor performs real-time encryption and decryption operations on system memory pages marked as encrypted: when the processor core of the secure virtual machine writes data to memory, the plaintext data is encrypted by the memory encryption key and stored in ciphertext form in physical memory; when the processor core reads data from memory, the ciphertext data in physical memory is decrypted in real-time by the memory encryption key and provided to the processor core in plaintext form. Meanwhile, the processor's built-in trusted key management module manages the entire lifecycle of the memory encryption key, including its generation, storage, update, and destruction, ensuring that the plaintext of the memory encryption key never appears in the system's main memory, thereby eliminating the risk of stealing the memory encryption key through memory scanning or cold start attacks.

[0052] On the other hand, in order to provide high-performance and high-security cryptographic computing capabilities and ensure the security of keys throughout their entire lifecycle, it is necessary to configure intrinsic cryptographic service capabilities.

[0053] Regarding this step, in some possible implementations, a trusted platform module can be deployed in a secure virtual machine. The user key can be sealed inside the trusted platform module through its data sealing function, and the expected value and authorization code of the platform configuration register can be set. Cryptographic operation services can be provided through the cryptographic coprocessor built into the CPU. The cryptographic operation services include at least one of the SM2 algorithm, SM3 algorithm, SM4 algorithm, and a true random number generator. An SDF extension interface can be provided through the business interface. The SDF extension interface is used to call the cryptographic coprocessor to perform cryptographic operations.

[0054] More specifically, the detailed process of configuring built-in cryptographic service capabilities includes: First, deploying and initializing a trusted platform module within a secure virtual machine. This trusted platform module is a hardware module for secure storage and encrypted computation. Utilizing the data sealing function provided by the trusted platform module, the user key is bound and encrypted with the current state value of the platform configuration register of the trusted platform module. The encrypted user key is then securely sealed and stored in the non-volatile storage area within the trusted platform module. Simultaneously, the expected value of the platform configuration register and an access authorization code are set for this sealing operation. The user key can only be unsealed and used if the actual measured value of the platform configuration register after system startup matches the preset expected value and the correct authorization code is provided. Next, activating and configuring the CPU's built-in cryptographic coprocessor. This cryptographic coprocessor is a hardware unit dedicated to performing cryptographic algorithm operations, capable of providing cryptographic computation services including but not limited to SM2, SM3, SM4 algorithms, and a true random number generator. All cryptographic operations are completed within the CPU chip; the keys and intermediate data during the operation are not exposed to system memory. Finally, an SDF extension interface conforming to national cryptographic standards is loaded and provided in the operating system of the secure virtual machine. This SDF extension interface serves as a bridge between the upper-layer business application and the lower-layer cryptographic coprocessor. By calling this SDF extension interface, the business application can specify the algorithm type and input data. The SDF extension interface drives the cryptographic coprocessor to perform the corresponding cryptographic operations and returns the operation results to the business application, thereby realizing transparent calling of the underlying cryptographic hardware.

[0055] Then, based on the virtual machine's memory encryption capabilities and intrinsic cryptographic service capabilities, a trusted and secure computing environment is constructed.

[0056] Regarding this step, one possible implementation is to integrate and activate the configured virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities to form a unified trusted and secure computing environment. Specifically, the secure virtual machine serves as an isolated execution environment for running the medical health code generation and parsing algorithm, ensuring that all relevant data exists in encrypted form in memory. Simultaneously, the intrinsic cryptographic service capability provides cryptographic support within this environment, with all encryption, decryption, signature verification, and other operations completed internally by calling the CPU's built-in cryptographic coprocessor through the SDF extension interface. This combination constructs a trusted and secure computing environment that possesses both memory data confidentiality protection and high-strength cryptographic computation capabilities, providing end-to-end security for subsequent sensitive data processing.

[0057] In this embodiment, a trusted and secure computing environment integrating virtual machine memory encryption and intrinsic cryptographic services is constructed, addressing the security vulnerabilities of traditional computing environments, such as the vulnerability of memory data to theft, low efficiency of cryptographic operations, and reliance on external hardware. Specifically, the virtual machine memory encryption capability achieves hardware-level isolation from the host and other virtual machines by creating a secure virtual machine with independent cache and translation backup buffer resources. It also encrypts system memory pages in real time using a processor-generated memory encryption key, ensuring that plaintext data written to memory is encrypted and ciphertext data read from memory is decrypted in real time. This guarantees data confidentiality during processing; even if the host is compromised, attackers cannot access the plaintext data in the secure virtual machine's memory. Simultaneously, the intrinsic cryptographic services capability deploys a trusted platform module within the secure virtual machine, utilizing its data sealing function to securely seal user keys internally. Combined with the CPU's built-in cryptographic coprocessor, it provides cryptographic operation services, including SM2, SM3, and SM4 algorithms, which are then accessed externally through the SDF extension interface. This achieves hardware-level isolation protection of keys and high-performance cryptographic operations. The two work together to provide a hardware root of trust for the generation and verification of medical health codes, ensuring the security and reliability of the entire data processing flow.

[0058] In one embodiment, for a better understanding of the entire process management of secure virtual machines during the construction of a trusted and secure computing environment, please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a schematic diagram illustrating the process of building and managing a secure virtual machine, as provided in an embodiment of this application.

[0059] Specifically, secure virtual machine creation is the starting step in the secure virtual machine-related process when constructing a trusted secure computing environment in this application embodiment. After the secure virtual machine creation is completed, the following configuration operations will be performed: secure virtual machine IP address management, secure virtual machine backup, secure virtual machine scheduling, secure virtual machine access control, and secure virtual machine migration. Secure virtual machine IP address management is used to achieve network isolation between the secure virtual machine and the host and other virtual machines, which meets the configuration requirements that the secure virtual machine has independent cache and translation backup buffer resources and is isolated from other entities. Secure virtual machine backup is used to protect the system memory page data stored in the secure virtual machine that is encrypted with the memory encryption key. Secure virtual machine scheduling is used to reasonably allocate computing resources while ensuring the independent resources of the secure virtual machine. Secure virtual machine access control is used to restrict unauthorized access to the secure virtual machine and further strengthen the isolation of the secure virtual machine. Secure virtual machine migration is used to adjust the running resources of the secure virtual machine without destroying the memory encryption state and intrinsic cryptographic service capabilities of the secure virtual machine.

[0060] In this embodiment, secure virtual creation corresponds to the step of creating a secure virtual machine when building a trusted secure computing environment. The aforementioned configuration operations such as secure virtual machine IP address management, secure virtual machine backup, secure virtual machine scheduling, secure virtual machine access control, and secure virtual machine migration are supporting operations in the configuration process of virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. After completing these configuration operations, secure virtual startup is performed. The secure virtual startup process interacts with the trusted platform module configured in the intrinsic cryptographic service capability, such as verifying the expected values ​​of the platform configuration registers, to ensure the security of the secure virtual machine startup process. After secure virtual startup is completed, the secure virtual machine management stage is entered. Secure virtual machine management is used to continuously manage and control the secure virtual machine that has been configured with virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities to maintain the stable operation of the trusted secure computing environment.

[0061] In one embodiment, for a better understanding of the architecture and interaction flow of the trusted platform module during the configuration of intrinsic cryptographic service capabilities in this application, please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the startup process and the interaction architecture of the trusted platform module provided in the embodiments of this application.

[0062] Specifically, the TPM shown in the diagram can be a Trusted Platform Module, the CPU can be a CPU, the PCR register can be a Platform Configuration Register, the PCR expected value can be the expected value of the Platform Configuration Register, the license code can be the license code, and key 1 and key 2 can be user keys. The boot process in the diagram is in the following order: BIOS, Grub, and OS. The three are connected by arrows to form a sequential boot process, and the BIOS, Grub, and OS all establish interactive connections with the PCR register in the TPM. At the same time, the CPU contains the TPM, and the TPM contains the PCR register, key 1, PCR expected value, key 2, PCR expected value, and license code.

[0063] In this embodiment, the above architecture is used to support the configuration of intrinsic cryptographic service capabilities: the CPU includes a TPM design, which provides a hardware-level operating platform for the trusted platform module, strengthens the isolation between the trusted platform module and the external environment, and adapts to the secure storage requirements of user keys; the interaction between the BIOS, Grub, and OS and the PCR register during the boot process can collect the actual measured value of the platform configuration register. This actual measured value can be compared with the expected value of PCR. Combined with the verification of the authorization code, the desealing of key 1 and key 2 and the control of usage permissions can be realized. This process corresponds to the implementation method of managing user keys through the data sealing function of the trusted platform module.

[0064] In one embodiment, for a better understanding of the software and hardware hierarchical architecture and interaction logic of cryptographic operations in the configuration of intrinsic cryptographic service capabilities in this application, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram illustrating the software and hardware hierarchy and component interactions for cryptographic operations provided in the embodiments of this application.

[0065] Specifically, this diagram divides the cryptographic architecture into two layers: a software layer and a hardware layer, separated by a dashed line. The software layer includes cryptographic protocols, cryptographic algorithms, and CCP drivers. The cryptographic protocol is connected to the cryptographic algorithm via arrows, forming a "cryptographic protocol to cryptographic algorithm" flow. The cryptographic algorithm is also connected to the CCP driver via arrows, forming a "cryptographic algorithm to CCP driver" flow. The hardware layer is a single module containing two parallel modules: a CPU and a CCP. The CPU contains a C86, which in turn contains a CIS, presenting a nested relationship of "hardware layer contains CPU, CPU contains C86, C86 contains CIS." Furthermore, there are inter-layer connections between the software and hardware layers: the cryptographic algorithm in the software layer is connected to the CIS within the C86 in the hardware layer via arrows, and the CCP driver in the software layer is connected to the CCP in the hardware layer via arrows. The CCP can be a cryptographic coprocessor built into the CPU, and the CIS can be a cryptographic instruction set module that supports cryptographic algorithm operations.

[0066] In this embodiment, the above architecture is used to support the configuration of cryptographic computation services for intrinsic cryptographic service capabilities: the cryptographic protocol in the software layer can correspond to the application protocol related to cryptographic computation, and the cryptographic algorithm can correspond to the algorithms involved in cryptographic computation services such as SM2, SM3, and SM4 algorithms; the CCP in the hardware layer, as a cryptographic coprocessor built into the CPU, can execute cryptographic computation services, and the CIS, as a cryptographic instruction set module, can assist in executing cryptographic algorithm computations; the cryptographic algorithms in the software layer, driven by the CIS and CCP through the interaction with the CCP, can rely on the resources of the hardware layer to improve the performance of cryptographic computations, which meets the configuration requirements of intrinsic cryptographic service capabilities to provide high-performance cryptographic computation services.

[0067] In one embodiment, the step "in a trusted and secure computing environment, preprocessing and extracting data from the initial identity information of the first user based on virtual machine memory encryption capabilities to obtain health code generation factor data" can be further refined and may include the following steps: In a trusted and secure computing environment, based on the virtual machine memory encryption capability, the document type code, document number, name, regional factor and reserved control factor in the initial identity information of the first user are standardized to obtain standardized identity information. The standardized identity information is converted according to the UTF-8 encoding format to obtain a UTF-8 encoded string; Extract a specified number of bytes from a UTF-8 encoded string to serve as the health code generation factor data.

[0068] Specifically, to convert the initial identity information of the first user into a unified and standardized data format, eliminate data source differences, and lay the foundation for subsequent encoding and encryption processing, it is necessary to perform data standardization processing on the document type code, document number, name, regional factor, and reserved control factor in the initial identity information of the first user in a trusted and secure computing environment, based on the virtual machine memory encryption capability, to obtain standardized identity information. Here, the document type code refers to the code used to identify the type of document, such as the code for an ID card or passport; the document number refers to the unique document number corresponding to the document type code; the name refers to the first user's legal name; the regional factor refers to the code used to identify the administrative division or institution to which the first user belongs; the reserved control factor refers to configurable parameters reserved for future functional expansion or specific business needs; data standardization processing refers to a series of standardized operations such as format unification, character set conversion, illegal character filtering, and length verification on various types of input data; standardized identity information refers to the data set that is uniformly formatted and conforms to predetermined specifications after data standardization processing.

[0069] Regarding this step, in some possible implementations, within a trusted and secure computing environment, the initial identity information of the first user is first validated for its document type code, document number, name, regional factor, and reserved control factor to ensure compliance with predefined data format specifications. Then, character set conversion is performed on each validated data item, uniformly converting it to the UTF-8 character set. Next, the converted text data, such as the name, undergoes cleaning operations such as removing leading and trailing spaces and replacing special characters. Finally, according to a preset data structure order, the processed document type code, document number, name, regional factor, and reserved control factor are concatenated, and the concatenated result is used as standardized identity information.

[0070] Next, the standardized identity information is converted according to the UTF-8 encoding format to obtain a UTF-8 encoded string. UTF-8 encoding format refers to a variable-length Unicode character encoding that can represent a character using 1 to 4 bytes; a UTF-8 encoded string is the byte sequence generated after converting all characters in the standardized identity information according to the UTF-8 encoding format.

[0071] Regarding this step, some possible implementations involve calling an encoding conversion module within a trusted and secure computing environment. This module takes standardized identity information as input and converts it according to the UTF-8 encoding format, generating a UTF-8 encoded string consisting of consecutive bytes. This conversion process ensures a unified representation of different languages ​​and symbols, avoiding garbled text issues caused by inconsistent encoding.

[0072] Then, a specified number of bytes are extracted from the UTF-8 encoded string to serve as the health code generation factor data. Here, the specified number of bytes refers to the pre-set byte length used to generate the health code according to the requirements of the health code generation algorithm; the health code generation factor data refers to the fixed-length data extracted from the UTF-8 encoded string that is directly input to the subsequent health code generation algorithm.

[0073] Regarding this step, in some possible implementations, a data truncation operation can be performed on the UTF-8 encoded string based on a preset specified number of bytes. Specifically, a specified number of bytes can be extracted continuously from the beginning of the UTF-8 encoded string, and this extracted data segment can be used as the health code generation factor data. If the total length of the UTF-8 encoded string is less than the specified number of bytes, the insufficient part can be padded using a preset padding rule to ensure that the length of the health code generation factor data is consistent with the specified number of bytes.

[0074] In this embodiment, the initial identity information of the first user is transformed from multi-source and heterogeneous initial identity information into health code generation factor data with a unified format and fixed length by performing data standardization, UTF-8 encoding conversion, and fixed-length data extraction. This process is completed in a trusted and secure computing environment based on virtual machine memory encryption capabilities, ensuring the confidentiality of the initial identity information throughout the processing. The generated health code generation factor data provides standardized input for subsequent encoding, masking, and encryption operations, ensuring the determinism and repeatability of the medical health code generation process.

[0075] In one embodiment, the above step of "in a trusted and secure computing environment, encoding and converting the health code generation factor data based on the intrinsic cryptographic service capability to obtain the first basic code data, and performing dynamic masking, dynamic encryption, and signature protection processing based on the first basic code data to generate the first user's first medical health code" can be further refined and may include the following steps: In a trusted and secure computing environment, the document type code, document number and name in the health code generation factor data are converted and concatenated to obtain the original data string; The first check code is determined based on the original data string, and the first check code is appended to the end of the original data string to obtain the first basic code data. Based on the first checksum, a corresponding random number is selected from the preset mask library as the first HMAC key; Based on the intrinsic cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the first basic code data and the first HMAC key to obtain the first protected identity code. The first intermediate spliced ​​data is obtained by concatenating the first protected identity code with the first organization identifier corresponding to the first user; A first dynamic identifier is generated based on the first check code, and a first initial vector is selected from the mask library based on the first dynamic identifier; Based on the intrinsic cryptographic service capability, the SM4 algorithm is invoked, and the first intermediate concatenated data is encrypted using the CBC mode, the group key corresponding to the first organization identifier, and the first initial vector to obtain the first encrypted data. The first encrypted data is concatenated with the first dynamic identifier to obtain the first medical identity identifier; Based on the endogenous cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the first institution identifier is used to digitally sign the first medical identity identifier to obtain the first signature value. Based on blockchain smart contracts, the first encrypted identity credential is generated by binding the first medical identity identifier, the first signature value and the medical health code generation request digest execution spatiotemporal information of the first user. The first user's first medical health code is generated based on the first encrypted identity credential.

[0076] Specifically, the first step is to perform character encoding conversion and concatenation on the document type code, document number, and name in the health code generation factor data within a trusted and secure computing environment to obtain the original data string. Character encoding conversion and concatenation refers to the process of converting different data items according to a unified character encoding standard and then concatenating the converted data items in a predetermined order to form a continuous string. The original data string refers to the initial data sequence generated from the document type code, document number, and name after character encoding conversion and concatenation, used for subsequent verification code calculation.

[0077] Regarding this step, in some possible implementations, the encoding conversion module within a trusted and secure computing environment can be invoked to perform character encoding conversion operations on the document type code, document number, and name in the health code generation factor data, ensuring that all data items adopt a unified character encoding format. Subsequently, in a predetermined order of document type code first, document number in the middle, and name last, the converted data items are sequentially concatenated, and the concatenated continuous string is used as the original data string.

[0078] Furthermore, a first checksum is determined based on the original data string, and the first checksum is appended to the end of the original data string to obtain the first basic code data. Here, the first checksum refers to short data generated by calculating the original data string according to a specific checksum algorithm, used to verify data integrity; the first basic code data refers to a data unit with self-verification capability, constructed by concatenating the original data string and its corresponding first checksum.

[0079] Regarding this step, in some possible implementations, a preset verification algorithm can be used to calculate the original data string, generate a fixed-length verification value, use this verification value as the first verification code, and then append the first verification code to the end of the original data string to form a combined data containing the original data and verification information. This combined data is used as the first basic code data.

[0080] Further, a corresponding random number is selected from a preset mask library as the first HMAC key based on the first checksum. Here, the mask library refers to a pre-configured dataset storing multiple random numbers, each of which has a preset mapping relationship with one or more checksum values; random numbers refer to values ​​with high randomness and unpredictability; and the first HMAC key refers to the key selected from the mask library for HMAC-SM3 calculation.

[0081] Regarding this step, in some possible implementations, the first checksum can be used as a query index to perform a matching search in a preset mask library, and a random number uniquely associated with the first checksum can be determined according to a preset mapping relationship, and this random number can be used as the first HMAC key.

[0082] Furthermore, based on the inherent cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the first basic code data and the first HMAC key to obtain the first protection identity code. Here, the SM3 algorithm refers to a hash algorithm recognized by the State Cryptography Administration; HMAC-SM3 calculation refers to a hash-based message authentication code calculation method implemented using the SM3 algorithm; and the first protection identity code refers to the authentication code generated through HMAC-SM3 calculation, used to protect the integrity and authenticity of the first basic code data.

[0083] Regarding this step, in some possible implementations, the first basic code data and the first HMAC key can be used as input parameters through the SDF extension interface provided by the endogenous cryptographic service capability. The cryptographic coprocessor is then called to perform the HMAC-SM3 operation. After the cryptographic coprocessor completes the calculation using the SM3 algorithm, the output fixed-length digest value is used as the first protection identity code.

[0084] Furthermore, the first protected identity code is concatenated with the first organization identifier corresponding to the first user to obtain the first intermediate concatenated data. Here, the first organization identifier corresponding to the first user refers to the coded information used to uniquely identify the organization or institution to which the first user belongs; the first intermediate concatenated data refers to the intermediate data formed by concatenating the first protected identity code and the first organization identifier, used for subsequent encryption processing.

[0085] Regarding this step, in some possible implementations, the first protection identity code can be concatenated with the first organization identifier corresponding to the first user, following the order of first protection identity code first and first organization identifier last. The concatenated data can then be used as the first intermediate concatenated data.

[0086] Further, a first dynamic identifier is generated based on the first checksum, and a first initialization vector is selected from the mask library based on the first dynamic identifier. Here, the first dynamic identifier refers to an identifier with dynamically changing characteristics generated based on the first checksum using a specific transformation algorithm; the first initialization vector refers to the input data used to initialize the encryption process in the CBC mode of the block cipher.

[0087] Regarding this step, in some possible implementations, a preset transformation operation can be performed on the first check code, such as performing a shift, XOR, or modulo operation to generate a value that is related to but different from the first check code, and this value is used as the first dynamic identifier; then, the first dynamic identifier is used as the query index to search in the mask library, and the random number associated with the first dynamic identifier is used as the first initial vector.

[0088] Furthermore, based on the inherent cryptographic service capability, the SM4 algorithm is invoked, and the first intermediate concatenated data is encrypted using CBC mode, the group key corresponding to the first organization identifier, and the first initialization vector to obtain the first encrypted data. Here, SM4 algorithm refers to a block cipher algorithm recognized by the State Cryptography Administration; CBC mode refers to Cipher Block Chaining mode, a working mode of block ciphers; and the group key corresponding to the first organization identifier refers to the symmetric key associated with the first organization identifier used for encryption operations.

[0089] Regarding this step, in some possible implementations, the SDF extension interface provided by the endogenous cryptographic service capability can be used to take the first intermediate concatenated data, the group key corresponding to the first organization identifier, the first initialization vector, and the working mode parameters specified as CBC mode as input, and call the cryptographic coprocessor to perform SM4 encryption operation. After the cryptographic coprocessor encrypts the first intermediate concatenated data in CBC mode, the output ciphertext data is the first encrypted data.

[0090] Furthermore, the first encrypted data is concatenated with the first dynamic identifier to obtain the first medical identity identifier.

[0091] Regarding this step, in some possible implementations, the first encrypted data and the first dynamic identifier can be concatenated in the order of first encrypted data first, followed by the first dynamic identifier, and the concatenated result can be used as the first medical identity identifier. Here, the first medical identity identifier refers to a composite data structure containing encrypted identity information and dynamic parameters required for decryption.

[0092] Furthermore, based on the inherent cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the first institution identifier is used to digitally sign the first medical identity identifier, obtaining the first signature value. Here, the SM2 algorithm refers to an elliptic curve-based asymmetric encryption algorithm recognized by the State Cryptography Administration; the platform key corresponding to the first institution identifier refers to the private key associated with the first institution identifier used for digital signing; digital signing refers to the technology of using a private key to encrypt data and generate a signature, which allows others to verify the data source and integrity using the corresponding public key; and the first signature value refers to the signature data generated after digitally signing the first medical identity identifier.

[0093] Regarding this step, in some possible implementations, the SDF extension interface provided by the intrinsic cryptographic service capability can be used to take the first medical identity identifier as the data to be signed, the platform key corresponding to the first institution identifier as the signing private key, and call the cryptographic coprocessor to perform SM2 signature operation. The result output by the cryptographic coprocessor after completing the signature calculation is the first signature value.

[0094] Furthermore, based on a blockchain smart contract, a first encrypted identity credential is generated by binding the first medical identity identifier, the first signature value, and the first user's medical health code generation request digest execution spatiotemporal information. Here, the blockchain smart contract refers to program code deployed on the blockchain that executes automatically when preset conditions are met; the first user's medical health code generation request digest refers to the digest value generated by hashing relevant data (such as timestamps, random numbers, etc.) when the first user initiates a health code generation request; and the first encrypted identity credential refers to a digital credential with immutable characteristics formed by storing the first medical identity identifier, the first signature value, and related digest information on-chain through a smart contract.

[0095] Regarding this step, in some possible implementations, the first medical identity identifier, the first signature value, and the first user's medical health code generation request digest can be used as parameters to call the smart contract interface deployed on the blockchain. After verifying the validity of the parameters, the smart contract binds these parameters with the current blockchain timestamp and packages the bound transaction records into the blockchain to generate a unique transaction hash. This transaction hash or the on-chain record containing the hash is the first encrypted identity credential.

[0096] Furthermore, a first medical health code for the first user is generated based on the first encrypted identity credential.

[0097] Regarding this step, in some possible implementations, the first encrypted identity credential itself, or the data generated after further encoding the credential (such as QR code encoding), can be output or stored as the first user's first medical health code.

[0098] In this embodiment, a complete process is executed sequentially within a trusted and secure computing environment. This process involves generating first basic code data based on the original data string and a first checksum; performing HMAC-SM3 calculation using a first HMAC key to obtain a first protected identity code; encrypting the first data using SM4-CBC with the first organization identifier to obtain first encrypted data; performing SM2 digital signature using the platform key to obtain a first signature value; and finally generating a first encrypted identity credential through spatiotemporal information binding via a blockchain smart contract. This constructs a multi-layered encryption architecture encompassing dynamic masking, dynamic encryption, and signature protection. This architecture ensures that the initial identity information of the first user is protected by hardware-level isolation and cryptographic safeguards at every stage of the generation process, making the first medical health code confidential, complete, and unforgeable. Furthermore, blockchain-based evidence storage guarantees its traceability, effectively addressing the security risks associated with directly using sensitive information, storing data in plaintext in memory, low cryptographic efficiency, and reliance on external hardware in related technologies.

[0099] In one embodiment, for easier understanding of the hierarchical architecture of the health code encryption algorithm technology and the corresponding processing flow of each layer in this application, please refer to [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram illustrating the hierarchical distribution and core module composition of the health code encryption algorithm technology provided in the embodiments of this application.

[0100] Specifically, Figure 5The hierarchical architecture of the health code encryption algorithm is vertically distributed, comprising a basic conversion layer, a three-layer encryption module, and a blockchain evidence storage layer. The basic conversion layer is located above the three-layer encryption module, and the blockchain evidence storage layer is located below it. The three-layer encryption module is the core module of this architecture, containing three sub-layers arranged vertically: a dynamic masking layer, a dynamic encryption layer, and a signature protection layer. Specifically, the basic conversion layer corresponds to the character encoding conversion and concatenation of health code generation factor data to generate the first basic code data in this embodiment; the dynamic masking layer corresponds to the HMAC-SM3 calculation process performed by calling the SM3 algorithm based on the endogenous cryptographic service capability in this embodiment; the dynamic encryption layer corresponds to the encryption process performed by calling the SM4 algorithm based on the endogenous cryptographic service capability in this embodiment; the signature protection layer corresponds to the digital signature process performed by calling the SM2 algorithm based on the endogenous cryptographic service capability in this embodiment; and the blockchain evidence storage layer corresponds to the generation of encrypted identity credentials based on the spatiotemporal information binding during the execution of blockchain smart contracts in this embodiment.

[0101] In this embodiment, the above-mentioned hierarchical architecture corresponds to the complete process of generating the first medical health code: the basic conversion layer provides self-verifying first basic code data for subsequent encryption operations, ensuring the standardization and integrity of the initial data; the three-layer encryption module, as the core protection unit, sequentially calls the corresponding cryptographic algorithms through the dynamic mask layer, dynamic encryption layer, and signature protection layer, relying on the inherent cryptographic service capabilities, to achieve layered and progressive protection of the data, ensuring the confidentiality and authenticity of the data during processing; the blockchain evidence storage layer performs on-chain evidence storage and binding of the results after multi-layer encryption processing, further strengthening the traceability and immutability of the data. This hierarchical architecture, in conjunction with the trusted and secure computing environment, ensures that every step of the health code generation process is within the scope of security protection, effectively supporting the goal of the first medical health code possessing confidentiality, integrity, and unforgeability.

[0102] In one embodiment, this embodiment provides a complete process for generating a first medical health code. For easier understanding of the technical solutions used in this process, please refer to [reference needed]. Figure 5 The diagram illustrates a hierarchical architecture. Specifically, this hierarchical architecture is distributed vertically and includes a basic conversion layer, a three-layer encryption module, and a blockchain evidence storage layer. The basic conversion layer is located above the three-layer encryption module, and the blockchain evidence storage layer is located below the three-layer encryption module. The three-layer encryption module is the core module of this architecture, and it contains three sub-layers arranged in vertical order: a dynamic mask layer, a dynamic encryption layer, and a signature protection layer.

[0103] In this embodiment, the process of generating the first medical health code corresponds to the above-mentioned hierarchical architecture and specifically includes the following steps: In a trusted and secure computing environment, the document type code, document number, and name in the health code generation factor data are converted and concatenated using character encoding to obtain the original data string; the mathematical expression for this process is: .in, Represents the original data string; Indicates the document type code; Indicates the document number; Indicates name; This indicates a string concatenation operation. This step corresponds to... Figure 5 The basic conversion layer shown.

[0104] The first checksum is determined based on the original data string, and then appended to the end of the original data string to obtain the first basic code data; the mathematical expression for this process is: and .in, This represents the first checksum; This represents the verification algorithm function; Represents the original data string; This represents the first basic code data; This indicates a string concatenation operation. This step also corresponds to... Figure 5 The basic conversion layer shown.

[0105] Based on the first verification code, a corresponding random number is selected from a preset mask library as the first HMAC key; based on the intrinsic cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the first basic code data and the first HMAC key to obtain the first protected identity code; the calculation algorithm is as follows: .in, This indicates the first protected identity code; This represents the first basic code data; This represents the first HMAC key, which is a random number selected from the mask library based on the first checksum; Indicates the XOR operation; and External and internal padding constants defined in the HMAC algorithm; This indicates a connection operation. This step corresponds to... Figure 5 The dynamic mask layer shown.

[0106] The first intermediate concatenation data is obtained by concatenating the first protected identity code with the first organization identifier corresponding to the first user; the organization identifier generation rule is as follows: The concatenated expression is .in, Indicates the identity of the first organization, by Generated through hash operation; This indicates the first intermediate concatenation of data; This indicates the first protected identity code; This indicates a string concatenation operation.

[0107] A first dynamic identifier is generated based on the first checksum, and a first initial vector is selected from the mask library based on the first dynamic identifier; the calculation algorithm is as follows: .in, Indicates the first dynamic identifier; Indicates a transformation operation; This represents the first checksum. The first initialization vector is based on... The corresponding random number selected from the mask library.

[0108] Based on the intrinsic cryptographic service capability, the SM4 algorithm is invoked, and the first intermediate concatenated data is encrypted using CBC mode, the group key corresponding to the first organization identifier, and the first initialization vector to obtain the first encrypted data. Specifically, based on the group key corresponding to the first organization identifier and the first initialization vector, the first intermediate concatenated data is padded with PKCS7 to obtain padded first intermediate concatenated data, which meets the block length requirements of the SM4 algorithm. The padded first intermediate concatenated data is divided into multiple data blocks according to the block size. Based on the intrinsic cryptographic service capability, the SM4 algorithm-based encryption operation is performed on each data block in the multiple data blocks using CBC mode to obtain the ciphertext block corresponding to each data block in the multiple data blocks. Among them, the ciphertext block corresponding to the first data block in the multiple data blocks is obtained by XORing the first data block with the first initialization vector and then encrypting it; the ciphertext blocks corresponding to the data blocks after the first data block are obtained by XORing the data blocks after the first data block with the previous ciphertext block and then encrypting them. The ciphertext blocks corresponding to each data block in the multiple data blocks are concatenated in sequence to obtain the first encrypted data. The calculation process, taking CBC mode as an example, is as follows: It is necessary to... Perform PKCS7 padding to make its length match the grouping length: .in, This represents the first intermediate concatenation data after filling; Indicates PKCS7 fill operation; This indicates the first intermediate concatenation of data. Divide the data into N blocks according to the group size: Perform the SM4 block encryption process, making For ciphertext blocks The calculation formula is: .in, Indicates the first Each data block corresponds to a ciphertext block; This indicates the use of the group key corresponding to the first organization identifier. SM4 encryption operation; Indicates the first One data block; Indicates the XOR operation; Indicates the previous ciphertext block, The first initial vector . .in, This represents the first encrypted data; This indicates a string concatenation operation. This step corresponds to... Figure 5 The dynamic encryption layer shown.

[0109] The first encrypted data is concatenated with the first dynamic identifier to obtain the first medical identity identifier; the expression for generating the medical identity identifier MID is: .in, Indicates primary medical identity; This represents the first encrypted data; Indicates the first dynamic identifier; This indicates a string concatenation operation.

[0110] Based on the intrinsic cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the first organization identifier is used to digitally sign the first medical identity identifier, obtaining the first signature value. Specifically, the SDF extension interface based on the intrinsic cryptographic service capability inputs the first medical identity identifier to the cryptographic coprocessor. Inside the cryptographic coprocessor, the security processor and key coprocessor use the platform key corresponding to the first organization identifier to perform a signature operation based on the SM2 algorithm on the first medical identity identifier, obtaining the first signature value. The signature SIGN generation expression is: .in, Indicates the first signature value; This refers to the SM2 digital signature algorithm; This indicates the platform key corresponding to the first organization's identifier; This indicates the primary medical identity identifier. This step corresponds to... Figure 5 The signature protection layer shown.

[0111] Based on a blockchain smart contract, a first encrypted identity credential is generated by binding the first medical identity identifier, the first signature value, and the first user's medical health code generation request digest with spatiotemporal information. Specifically, a first current timestamp is obtained; the first medical identity identifier, the first signature value, the first user's medical health code generation request digest, and the first current timestamp are input into the blockchain smart contract as binding parameters; the first signature value is verified through the blockchain smart contract to obtain a first verification result; if the first verification result indicates that the verification is successful, the first medical identity identifier, the timestamp, and the first user's medical health code generation request digest are stored on-chain in a privacy-preserving manner through the blockchain smart contract to generate the first encrypted identity credential. ,in, This represents the first encrypted identity credential; This refers to blockchain smart contracts; Indicates primary medical identity; Indicates the first signature value; This represents the summary of the first user's medical health code generation request. This step corresponds to... Figure 5 The blockchain evidence storage layer is shown. Finally, a first user's first medical health code can be generated based on the first encrypted identity credential.

[0112] In one embodiment, the step "invoking the SM4 algorithm based on the intrinsic cryptographic service capability, encrypting the first intermediate concatenated data using CBC mode, the group key corresponding to the first organization identifier, and the first initialization vector to obtain the first encrypted data" can be further refined and may include the following steps: Based on the group key corresponding to the first organization identifier and the first initial vector, the first intermediate concatenation data is padded with PKCS7 to obtain the padded first intermediate concatenation data. The padded first intermediate concatenation data meets the block length requirements of the SM4 algorithm. The first intermediate concatenated data after filling is divided into multiple data blocks according to the group size; Based on the inherent cryptographic service capability, the CBC mode is used to perform encryption operation based on the SM4 algorithm on each data block in multiple data blocks to obtain the ciphertext block corresponding to each data block in multiple data blocks; Among them, the ciphertext block corresponding to the first data block in the multiple data blocks is obtained by encrypting the first data block and the first initial vector by performing an XOR operation; the ciphertext block corresponding to the data block after the first data block is obtained by encrypting the data block after the first data block and the previous ciphertext block by performing an XOR operation. The ciphertext blocks corresponding to each of the multiple data blocks are concatenated in sequence to obtain the first encrypted data.

[0113] Specifically, firstly, based on the group key corresponding to the first institution identifier and the first initialization vector, the first intermediate concatenated data needs to be padded with PKCS7 to obtain padded first intermediate concatenated data. The padded first intermediate concatenated data conforms to the block length requirement of the SM4 algorithm. Here, PKCS7 padding refers to a padding scheme used in cryptography to pad data so that its length meets the block size requirement of block cipher algorithms; the padded first intermediate concatenated data refers to the data to be encrypted after PKCS7 padding, whose total length is an integer multiple of the block length; the block length requirement of the SM4 algorithm means that the SM4 algorithm, as a block cipher, has a fixed byte length for each data block it processes.

[0114] Regarding this step, in some possible implementations, the difference between the current length of the first intermediate concatenation data and the SM4 algorithm block length can be calculated. Based on this difference, the number of bytes N to be padded can be determined. Then, N bytes with the value N are generated and appended to the end of the first intermediate concatenation data to form the padded first intermediate concatenation data.

[0115] Furthermore, the padded first intermediate concatenated data is divided into multiple data blocks according to the group size. These multiple data blocks refer to several data units formed by dividing the padded first intermediate concatenated data into equal-length segments according to the group length of the SM4 algorithm.

[0116] Regarding this step, in some possible implementations, one can start from the beginning of the first intermediate concatenated data after padding, and sequentially truncate the data according to the group length of the SM4 algorithm, taking one group length of data as a data block each time, and repeating this process until the entire first intermediate concatenated data after padding is completely divided, thus obtaining multiple data blocks.

[0117] Furthermore, based on the inherent cryptographic service capability, the SM4-based encryption operation is performed on each data block in the multiple data blocks using CBC mode to obtain the ciphertext block corresponding to each data block. Here, the ciphertext block corresponding to each data block refers to the corresponding ciphertext data unit output after performing the SM4 encryption operation on each plaintext data block in CBC mode.

[0118] Regarding this step, in some possible implementations, the SDF extension interface provided by the endogenous cryptographic service capability can be used to take multiple data blocks, the group key corresponding to the first organization identifier, the first initialization vector, and the working mode parameters specified as CBC mode as inputs, call the cryptographic coprocessor, and the cryptographic coprocessor will perform SM4 encryption operation on each data block in sequence according to the encryption logic of CBC mode, and take the result of each operation as the ciphertext block corresponding to that data block.

[0119] The ciphertext block corresponding to the first data block among the multiple data blocks is obtained by encrypting the first data block and the first initial vector by performing an XOR operation; the ciphertext block corresponding to the data blocks after the first data block is obtained by encrypting the data blocks after the first data block and the previous ciphertext block by performing an XOR operation.

[0120] Finally, the ciphertext blocks corresponding to each data block in the multiple data blocks are concatenated in sequence to obtain the first encrypted data.

[0121] In this embodiment, by padding the first intermediate concatenated data with PKCS7, the data length is ensured to meet the block length requirements of the SM4 algorithm, providing standardized input for subsequent block encryption operations. By dividing the padded data into multiple data blocks, and in CBC mode, XORing the first data block with the first initialization vector and then encrypting it, and using the previous ciphertext block to chain and encrypt subsequent data blocks, the encryption process of each data block depends on its preceding data. This enhances the diffusion of encryption, ensuring that even minor modifications to the ciphertext will cause all subsequent decryption to fail. The entire encryption process is completed in a trusted and secure computing environment by calling a cryptographic coprocessor through the built-in cryptographic service capability, ensuring the efficiency and security of the encryption operation. The final generated first encrypted data has a high degree of confidentiality.

[0122] In one embodiment, the step "calling the SM2 algorithm based on the intrinsic cryptographic service capability, using the platform key corresponding to the first institution identifier to digitally sign the first medical identity identifier, and obtaining the first signature value" can be further refined and may include the following steps: The SDF extension interface, based on the built-in cryptographic service capability, inputs the first medical identity identifier into the cryptographic coprocessor; Inside the cryptographic coprocessor, the security processor and the key coprocessor use the platform key corresponding to the first organization identifier to perform a signature operation based on the SM2 algorithm on the first medical identity identifier to obtain the first signature value.

[0123] Specifically, the first step is to input the first medical identity identifier into the cryptographic coprocessor based on the SDF extension interface, which utilizes the inherent cryptographic service capabilities. Referring to the aforementioned embodiments for constructing a trusted and secure computing environment, the SDF extension interface refers to a software interface conforming to national cryptographic standards and specifications, used by upper-layer applications to call lower-layer cryptographic services. It encapsulates the details of interaction with the cryptographic coprocessor. The cryptographic coprocessor refers to a hardware unit integrated within the CPU, dedicated to performing cryptographic algorithm operations, and capable of providing high-performance cryptographic computing capabilities.

[0124] Regarding this step, in some possible implementations, the business system can call the SDF extension interface provided by the intrinsic cryptographic service capability, pass the first medical identity identifier to be signed as an input parameter to the SDF extension interface, and after receiving the first medical identity identifier, the SDF extension interface sends the data to the cryptographic coprocessor inside the CPU through the driver.

[0125] Inside the cryptographic coprocessor, the security processor and the key coprocessor use the platform key corresponding to the first organization identifier to perform a signature operation based on the SM2 algorithm on the first medical identity identifier to obtain the first signature value.

[0126] Regarding this step, in some possible implementations, within the cryptographic coprocessor, the security processor is responsible for instruction scheduling and flow control, while the key coprocessor is responsible for the specific cryptographic calculations. After receiving the first medical identity identifier, the security processor retrieves the platform key corresponding to the first institution identifier from the secure storage area, then calls the key coprocessor to perform a signature operation based on the SM2 algorithm on the first medical identity identifier using the platform key, and outputs the result as the first signature value.

[0127] In this embodiment, the signature operation is offloaded to the cryptographic coprocessor within the CPU via the SDF extension interface. This ensures that the platform key, which is core sensitive data, and the first medical identity identifier to be signed remain within the security boundary of the CPU chip throughout the entire signature computation process. This process is collaboratively completed by the security processor and key coprocessor within the cryptographic coprocessor. The security processor is responsible for instruction scheduling and flow control, while the key coprocessor handles the specific cryptographic calculations, achieving hardware-level isolation protection for the key and data. This signature computation, performed within the chip, prevents information leakage caused by memory sniffing, side-channel attacks, etc., ensuring the security and credibility of the digital signature, thereby providing the first medical identity identifier with unforgeable and non-repudiable authentication protection.

[0128] In one embodiment, the above step "generating a first encrypted identity credential by binding the first medical identity identifier, the first signature value, and the medical health code generation request digest of the first user with spatiotemporal information based on a blockchain smart contract" can be further refined into the following steps: Get the first current timestamp; The first medical identity identifier, the first signature value, the first user's medical health code generation request summary, and the first current timestamp are input into the blockchain smart contract as binding parameters; The first signature value is verified using a blockchain smart contract to obtain the first verification result; If the first verification result indicates that the verification is successful, the first medical identity identifier, timestamp, and medical health code generation request summary of the first user are stored on the blockchain in a privacy-preserving manner through a blockchain smart contract to generate the first encrypted identity credential.

[0129] Specifically, in order to bind the generation time of the first medical identity credential to a timestamp on the blockchain, thereby providing a verifiable time reference for the credential and enhancing its timeliness and non-repudiation, it is necessary to obtain the first current timestamp. The first current timestamp refers to the time information used to identify the moment the first medical identity credential was generated; this time information is typically provided by a trusted time source.

[0130] Regarding this step, in some possible implementations, the first current timestamp can be obtained by calling the time service interface within the trusted and secure computing environment, or by synchronizing with a time source such as a time synchronization center.

[0131] Furthermore, the first medical identity identifier, the first signature value, the first user's medical health code generation request summary, and the first current timestamp are input into the blockchain smart contract as binding parameters.

[0132] Regarding this step, in some possible implementations, the first medical identity identifier, the first signature value, the first user's medical health code generation request digest, and the first current timestamp can be serialized to form a set of structured binding parameters. Then, the preset blockchain smart contract can be called through the application programming interface provided by the blockchain node, and the set of binding parameters can be passed to the blockchain smart contract as input parameters.

[0133] Furthermore, the first signature value is verified through a blockchain smart contract to obtain the first verification result. It is understandable that the first verification result may indicate either successful or unsuccessful verification.

[0134] Regarding this step, in some possible implementations, a signature verification operation can be performed on the first signature value, which is the input parameter, using a pre-stored public key corresponding to the first institution identifier within the blockchain smart contract. This verifies whether the first signature value was generated by signing the first medical identity identifier using the corresponding private key, and generates a first verification result based on the result of the verification operation.

[0135] Furthermore, if the first verification result indicates successful verification, the first medical identity identifier, timestamp, and the first user's medical health code generation request digest are stored on-chain using a privacy-preserving method via a blockchain smart contract to generate a first encrypted identity credential. Here, privacy-preserving method refers to a means of recording data on the blockchain in encrypted or hashed form to protect the privacy of the original data while ensuring its integrity and traceability; on-chain storage refers to the process of recording data or its digital fingerprint into the blockchain distributed ledger, utilizing the decentralized, immutable, and traceable characteristics of the blockchain to guarantee data security and trustworthiness.

[0136] Regarding this step, in some possible implementations, if the first verification result indicates that the verification is successful, the blockchain smart contract can use the first medical identity identifier, the first current timestamp, and the first user's medical health code generation request digest as the data to be stored. By calling the underlying transaction interface of the blockchain, a transaction containing the data to be stored is packaged and written into the blockchain, thereby generating a unique transaction hash. The transaction hash or the on-chain record containing the transaction hash is used as the first encrypted identity credential.

[0137] If the first verification result indicates that the verification fails, the blockchain smart contract terminates the evidence storage process and returns a verification failure indication message.

[0138] In this embodiment, the first medical identity identifier, the first signature value, the medical health code generation request digest, and the first current timestamp are input as binding parameters into the blockchain smart contract. The smart contract performs signature verification, ensuring the authenticity and integrity of the data to be stored. After successful verification, the smart contract performs on-chain storage of the above data in a privacy-preserving manner, generating the first encrypted identity credential. This process utilizes the immutability of the blockchain to provide a traceable storage record for the first medical identity identifier, while the introduction of a timestamp enables the time-sensitive binding of the credential. In this way, a multi-layered security protection system integrating identity authentication, data integrity, and time validity can be constructed for the first medical identity credential while ensuring data privacy.

[0139] In one embodiment, for easier understanding of the content regarding the hierarchical processing of identity identifiers and component interactions during the generation of medical health codes in this application, please refer to [link to relevant documentation]. Figure 6 , Figure 6 This is a schematic diagram illustrating the layered processing of identity identifiers and component interactions in the generation of medical health codes provided in this application embodiment.

[0140] Specifically, Figure 6 The identity processing architecture during the generation of medical health codes is divided into three layers: business system (application layer), CSV virtual machine (operating system layer), and CCP (within the Hygon CPU chip, chip layer). The interaction relationships between each layer and its internal processes and components are as follows: The workflow steps of the business system (application layer) are as follows: identity identification collection, identity identification processing, identity identification data standardization, identity identification generation, return of encrypted identity identification code, and subsequent processing; The process steps and interactions of the CSV virtual machine (operating system layer) are as follows: The CSV memory receives the output data of "identity identification data standardization" from the business system through "data temporary storage"; "start generating identification code" receives the call request of "identity identification generation" from the business system through "call"; after "start generating identification code", the kernel algorithm program is executed sequentially for further processing → identity identification code → encryption → persistent storage; the persistent storage passes the result to the business system's "return encrypted identity identification code" through "return"; wherein, the CSV virtual machine can be one of the secure virtual machines created when building the trusted secure computing environment in this application; The CCP (within the Hygon CPU chip, chip layer) includes pre-embedded components: keys, random numbers, etc. (pre-embedded within the chip), basic generation algorithms (pre-embedded within the chip), and basic encryption algorithms (pre-embedded within the chip). Its process flow is as follows: the keys and random numbers provide data to the basic generation algorithm via a "request"; the basic generation algorithm generates a basic identifier and passes it to the "kernel algorithm program for further processing" in the CSV virtual machine; the basic encryption algorithm receives the "encryption" request from the CSV virtual machine via a "call"; the CCP can be one type of cryptographic coprocessor built into the CPU in this application. Meanwhile, the connections and interactions between layers are as follows: between the business system and the CSV virtual machine, data and requests are transferred through "data temporary storage", "calling", and "returning"; between the CSV virtual machine and the CCP, collaboration between components is achieved through "calling" and data transfer.

[0141] In this embodiment, the identity identification collection, processing, and standardization steps of the business system correspond to the data preprocessing and data extraction steps for the initial identity information of the first user in this application. The CSV virtual machine, as a type of secure virtual machine, relies on its independent resources and isolation characteristics to accept requests from the business system and perform intermediate processing within a trusted and secure computing environment. Its CSV memory storage method meets the secure storage requirements under the virtual machine memory encryption capability. The CCP, as a type of cryptographic coprocessor built into the CPU, supports the cryptographic operation requirements of the intrinsic cryptographic service capability through pre-embedded basic generation algorithms, basic encryption algorithms, keys, random numbers, and other resources. Each layer works collaboratively through a predetermined interaction method to achieve secure processing of identity identification from collection and processing to encrypted storage, providing a secure identity identification data foundation for the generation of the first medical health code.

[0142] Please see Figure 7 , Figure 7 This is a flowchart illustrating a medical health code verification method provided in an embodiment of this application. Figure 7 As shown, the method in this application embodiment may include the following steps S201-S204.

[0143] S201, receiving the second user's second medical health code; S202, transmit the second medical health code to a trusted secure computing environment, which includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities; S203, In a trusted and secure computing environment, the second medical health code is signed and decrypted based on the endogenous cryptographic service capability to obtain the second basic code data, and then the second basic code data is demasked and decoded to obtain the second identity information. S204, verify the identity validity based on the second identity information and obtain the verification result.

[0144] The trusted and secure computing environment involved in this embodiment is the same as or equivalent to the trusted and secure computing environment in the embodiments related to the above-mentioned method for generating medical health codes.

[0145] Specifically, the first step is to receive the second user's second medical health code. This second medical health code may originate from the user's terminal actively displaying it through the application interface, being obtained by scanning a QR code with a scanning device, or being transmitted by other business systems via interface calls during cross-platform collaboration; these possibilities will not be listed here.

[0146] Regarding this step, in some possible implementations, a data packet containing the second medical health code sent by the second user or its authorized device can be received through a preset network communication interface or hardware input port, and the data packet can be initially format-checked to ensure that it conforms to the predefined data structure specifications.

[0147] Furthermore, to ensure that the verification process of the second medical health code is conducted in a hardware-level secure isolation environment and to prevent the leakage of sensitive information during processing, the second medical health code needs to be transmitted to a trusted secure computing environment. This trusted secure computing environment includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. The definitions of the trusted secure computing environment, virtual machine memory encryption capabilities, and intrinsic cryptographic service capabilities have been described in the above embodiments and will not be repeated here.

[0148] Regarding this step, in some possible implementations, the received second medical health code can be used as input data and transmitted through an internal secure channel to a secure virtual machine that has been started and has virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities, so that subsequent steps can be executed in the secure virtual machine.

[0149] Furthermore, in a trusted and secure computing environment, the second medical health code undergoes signature verification and decryption processing based on endogenous cryptographic service capabilities to obtain second basic code data. This second basic code data is then subjected to demasking and decoding conversion processing to obtain second identity information. Specifically, signature verification processing refers to a process of verifying the validity of a digital signature using public-key cryptography algorithms to confirm the authenticity of the data source and that the data has not been tampered with during transmission; decryption processing refers to a reverse operation corresponding to the encryption process, using a key to restore ciphertext data to plaintext data; the second basic code data refers to the data structure containing the original identity information and verification code obtained after decryption and demasking, its content corresponding to the first basic code data generated; demasking processing refers to an operation reversed from dynamic masking processing, verifying data integrity by reproducing the HMAC calculation process; decoding conversion processing refers to a reverse processing process of converting data in a specific character encoding format into readable text or standard data format; and the second identity information refers to the set of plaintext information ultimately obtained after the above series of processing, which can be used to identify the second user, such as document type code, document number, and name.

[0150] Regarding this step, in some possible implementations, within a trusted and secure computing environment, the second medical identity identifier and its corresponding second signature value are first parsed from the second medical health code. Then, based on the inherent cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the second institution identifier is used to verify the signature of the second medical identity identifier, obtaining a second verification result. If the second verification result indicates successful verification, the dynamic identifier and encrypted portion are separated from the second medical identity identifier, and the corresponding initialization vector is selected from a preset mask library based on the dynamic identifier. Next, based on the inherent cryptographic service capability, the SM4 algorithm is invoked, using CBC mode, the group key corresponding to the second institution identifier, and the initialization vector to decrypt the encrypted portion, obtaining the decrypted middle code. The process involves: concatenating intermediate data; separating the protection identity code and the second basic code data from the decrypted intermediate concatenated data; selecting a corresponding random number from a preset mask library based on a dynamic identifier as the HMAC key; invoking the SM3 algorithm based on the intrinsic cryptographic service capability to perform HMAC-SM3 calculation on the second basic code data and the HMAC key to obtain the identity code to be verified; comparing the identity code to be verified with the protection identity code to verify data integrity; if the verification passes, decoding the second basic code data using UTF-8 to obtain the second user's document type code, document number, and name; and determining the second identity information based on the second user's document type code, document number, name, and the second organization identifier in the decrypted intermediate concatenated data.

[0151] Furthermore, identity validity verification is performed based on the second identity information to obtain a verification result. Identity validity verification refers to a process that combines on-chain evidence storage information with local mapping relationships to comprehensively verify the second identity information, confirming its legality and timeliness. The verification result is the final output of the identity validity verification, used to indicate whether the second medical health code is valid. It is understandable that the verification result may indicate that the second medical health code is valid or invalid.

[0152] Regarding this step, some possible implementations include obtaining a second current timestamp; inputting the second medical identity identifier, the second signature value, the second user's medical health code generation request digest, and the second current timestamp into a blockchain smart contract; verifying the validity of the second signature value and the existence and tamper-proof of the encrypted identity credential corresponding to the second medical identity identifier through the blockchain smart contract; if the blockchain smart contract returns a successful verification, comparing the second identity information with the stored mapping relationship according to a preset mapping relationship rule to determine whether the user identity identifier stored in the mapping relationship matches the second identity information; if the user identity identifier stored in the mapping relationship matches the second identity information, the verification result is determined to be valid; if the user identity identifier stored in the mapping relationship does not match the second identity information, the verification result is determined to be invalid; wherein, the mapping relationship rule is a mapping relationship formed by binding user identity information with user identity identifier and institution identifier.

[0153] In this embodiment, the verification process of the second medical health code is executed in a trusted and secure computing environment. A multi-layered security verification mechanism corresponding to the generation process is constructed by comprehensively utilizing a series of operations, including signature verification, decryption, demasking, decoding conversion, and identity validity verification. This mechanism ensures the confidentiality and integrity of the second medical health code during the verification process, effectively preventing forgery and tampering. Simultaneously, through cross-verification with blockchain-stored information and local mapping relationships, the accuracy and credibility of the verification results are guaranteed, thus providing security for cross-system and cross-platform identity mutual recognition. Specifically, signature verification and decryption processing based on intrinsic cryptographic service capabilities ensure the source credibility and content confidentiality of the second medical identity identifier at the hardware level; demasking and decoding conversion processes reverse-engineer the second basic code data and verify its integrity; the final identity validity verification, by combining the spatiotemporal information binding of the blockchain smart contract with the comparison of the local mapping relationship, forms a dual verification through on-chain and off-chain collaboration, ensuring the validity of the verification results.

[0154] In one embodiment, the above step of "in a trusted and secure computing environment, performing signature verification and decryption processing on the second medical health code based on the endogenous cryptographic service capability to obtain second basic code data, and performing demasking and decoding conversion processing on the second basic code data to obtain second identity information" can be further refined and may include the following steps: In a trusted and secure computing environment, the second medical identity identifier and the corresponding second signature value are parsed from the second medical health code; Based on the endogenous cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the second institution identifier is used to sign and verify the second medical identity identifier to obtain the second verification result. If the second verification result indicates that the verification is successful, the second dynamic identifier and the encrypted part are separated from the second medical identity identifier, and the corresponding second initial vector is selected from the preset mask library based on the second dynamic identifier; Based on the intrinsic cryptographic service capability, the SM4 algorithm is invoked, and the encrypted part is decrypted using CBC mode, the group key corresponding to the second organization identifier, and the second initial vector to obtain the decrypted second intermediate concatenated data. Separate the second protected identity code and the second basic code data from the decrypted second intermediate concatenated data; The second dynamic identifier is used to select a corresponding random number from a preset mask library as the second HMAC key; Based on the intrinsic cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the second basic code data and the second HMAC key to obtain the identity code to be verified. The identity code to be verified is compared with the second protected identity code to verify data integrity; If the integrity check passes, the second basic code data is decoded into UTF-8 to obtain the second user's ID type code, ID number, and name; The second identity information is determined based on the second user's ID type code, ID number, and name, as well as the second organization identifier in the decrypted second intermediate concatenated data.

[0155] Specifically, the first step is to parse the second medical identity identifier and its corresponding second signature value from the second medical health code within a trusted and secure computing environment. The second medical identity identifier is a composite data structure formed by encrypting identity information during its generation process; it contains the encrypted identity information and dynamic parameters required for decryption. The second signature value is data generated by digitally signing the second medical identity identifier using an asymmetric algorithm, used to verify the source and integrity of the second medical identity identifier.

[0156] Regarding this step, in some possible implementations, the data format of the second medical health code can be parsed, and the encrypted data part constituting the core identity information can be extracted from it according to the predefined data structure rules. This encrypted data part is used as the second medical identity identifier, and at the same time, the digital signature data associated with the second medical identity identifier is extracted and used as the corresponding second signature value.

[0157] Furthermore, based on the intrinsic cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the second institution identifier is used to perform signature verification on the second medical identity identifier, resulting in a second verification result. Here, the platform key corresponding to the second institution identifier refers to the public key associated with the institution identifier to which the second medical health code generator belongs, used for signature verification; the second verification result refers to the output obtained after performing the signature verification operation, used to indicate whether the second signature value was generated by signing the second medical identity identifier using the corresponding private key.

[0158] Regarding this step, in some possible implementations, the second medical identity identifier and the second signature value can be used as input parameters through the SDF extension interface provided by the endogenous cryptographic service capability to call the cryptographic coprocessor; inside the cryptographic coprocessor, the platform key corresponding to the second institution identifier is used to perform a signature verification operation based on the SM2 algorithm on the second medical identity identifier, and the operation result is output as the second verification result.

[0159] Furthermore, a second dynamic identifier and an encrypted component are separated from the second medical identity identifier, and a corresponding second initialization vector is selected from a preset mask library based on the second dynamic identifier. Here, the second dynamic identifier refers to the identifier dynamically generated based on the checksum during the generation process, used to select encryption parameters; the encrypted component refers to the core identity data in the second medical identity identifier after processing with a symmetric encryption algorithm; the mask library refers to a data set storing multiple random numbers or initialization vectors, each parameter in the set having a preset mapping relationship with one or more dynamic identifiers; and the second initialization vector refers to the initialization vector corresponding to the second dynamic identifier required during the CBC mode decryption process.

[0160] Regarding this step, in some possible implementations, if the second verification result indicates that the verification is successful, the second dynamic identifier used for parameter selection and the encrypted part used for subsequent decryption can be separated from the second medical identity identifier according to the predetermined data segmentation rules; then, using the separated second dynamic identifier as an index, a query is performed in the preset mask library, and the initial vector uniquely associated with the second dynamic identifier is determined according to the preset mapping relationship, and the initial vector is used as the second initial vector.

[0161] Furthermore, based on the intrinsic cryptographic service capability, the SM4 algorithm is invoked, and the encrypted part is decrypted using CBC mode, the group key corresponding to the second organization identifier, and the second initialization vector to obtain the decrypted second intermediate concatenated data. Here, the group key corresponding to the second organization identifier refers to the key associated with the second organization identifier and used for symmetric decryption operations; the decrypted second intermediate concatenated data refers to the plaintext data containing the protection identity code and organization identifier, obtained after performing SM4-CBC decryption on the encrypted part.

[0162] Regarding this step, in some possible implementations, the SDF extension interface provided by the endogenous cryptographic service capability can be used to take the encrypted part, the group key corresponding to the second organization identifier, the second initialization vector, and the working mode parameters specified as CBC mode as inputs, and call the cryptographic coprocessor to perform SM4 decryption operation; after the cryptographic coprocessor decrypts the encrypted part in CBC mode, the plaintext data output is the decrypted second intermediate concatenation data.

[0163] Furthermore, the second protected identity code and the second basic code data are separated from the decrypted second intermediate spliced ​​data.

[0164] Regarding this step, in some possible implementations, the decrypted second intermediate concatenated data can be parsed according to the data concatenation rules set during the generation process, and divided into two parts: one part is the second protection identity code used for integrity verification, and the other part is the second basic code data used for subsequent decoding processing.

[0165] Furthermore, a corresponding random number is selected from a preset mask library based on the second dynamic identifier as the second HMAC key.

[0166] Regarding this step, in some possible implementations, the second dynamic identifier can be used as the query index to search in a preset mask library, and a random number uniquely associated with the second dynamic identifier can be determined according to the preset mapping relationship. This random number can then be used as the second HMAC key.

[0167] Furthermore, based on the intrinsic cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the second basic code data and the second HMAC key to obtain the identity code to be verified.

[0168] Regarding this step, in some possible implementations, the second basic code data and the second HMAC key can be used as input parameters through the SDF extension interface provided by the endogenous cryptographic service capability. The cryptographic coprocessor is then called to perform the HMAC-SM3 operation. After the cryptographic coprocessor completes the calculation using the SM3 algorithm, the output fixed-length digest value is used as the identity code to be verified.

[0169] Furthermore, the identity code to be verified is compared with the second protected identity code to verify data integrity.

[0170] Regarding this step, in some possible implementations, the calculated identity code to be verified can be compared byte by byte with the second protected identity code separated from the decrypted second intermediate concatenated data. If the two are completely consistent, the data integrity verification is deemed to have passed; otherwise, the data integrity verification is deemed to have failed.

[0171] Furthermore, if the integrity verification passes, the second basic code data is decoded using UTF-8 to obtain the second user's ID type code, ID number, and name.

[0172] Regarding this step, in some possible implementations, if the data integrity verification passes, the decoding and conversion module within the trusted and secure computing environment can be called. The second basic code data is taken as input, and it is reverse-decoded and converted according to the UTF-8 encoding format. The decoded text data is then divided according to a predetermined delimiter to obtain the second user's ID type code, ID number, and name.

[0173] Finally, the second identity information is determined based on the second user's ID type code, ID number, and name, as well as the second organization identifier in the decrypted second intermediate concatenated data.

[0174] Regarding this step, in some possible implementations, the second user's ID type code, ID number, and name can be combined with the second organization identifier parsed from the decrypted second intermediate concatenated data to form a complete data set containing user identity and affiliated organization information, and this data set can be used as the second identity information.

[0175] In this embodiment, a reverse verification mechanism strictly corresponding to the generation process is constructed by sequentially executing the following steps in a trusted and secure computing environment: signature verification, separation of dynamic parameters, symmetric decryption, data separation, integrity verification through HMAC calculation re-enactment, decoding conversion, and combination of identity information. This mechanism ensures that every step of the verification process of the second medical health code undergoes cryptographic verification, thereby guaranteeing the authenticity and integrity of the second identity information and providing a reliable data foundation for subsequent identity validity verification. Specifically, the signature verification step confirms the trustworthiness of the source of the second medical identity identifier; separating the second dynamic identifier and selecting the corresponding second initial vector ensures the correctness of the decryption process; the SM4-CBC decryption operation recovers the protected core data; by re-enacting the HMAC-SM3 calculation and comparing the identity code to be verified with the second protected identity code, the integrity of the second basic code data is verified; and the final UTF-8 decoding and information combination accurately restores the identity information of the second user.

[0176] In one embodiment, the above step "verifying identity validity based on the second identity information and obtaining the verification result" can be further refined and may include the following steps: Get the second current timestamp; Input the second medical identity identifier, the second signature value, the medical health code generation request summary of the second user and the second current timestamp into the blockchain smart contract, and verify the validity of the second signature value and the existence and tampering of the encrypted identity certificate corresponding to the second medical identity identifier through the blockchain smart contract; If the blockchain smart contract returns a successful verification, the second identity information is compared with the stored mapping relationship according to the preset mapping relationship rules to determine whether the user identity identifier stored in the mapping relationship matches the second identity information. If the user identity identifier stored in the mapping relationship matches the second identity information, the verification result is determined to be valid; If the user identity identifier stored in the mapping relationship does not match the second identity information, the verification result is determined to be invalid. Among them, the mapping relationship rule is a mapping relationship formed by binding user identity information with user identity identifier and organization identifier.

[0177] Specifically, in this embodiment, the second current timestamp refers to time data representing the current verification time; the second medical identity identifier refers to a composite data structure formed after encrypting identity information during the generation process, which contains encrypted identity information and dynamic parameters required for decryption; the second signature value refers to data generated after digitally signing the second medical identity identifier using an asymmetric algorithm, used to verify the source and integrity of the second medical identity identifier; the second user refers to the holder or user of the second medical health code; the medical health code generation request digest refers to the digest value calculated from the user's original application data when generating the second medical health code, used to trace the generation request on the blockchain; and the blockchain smart contract refers to the contract deployed on the blockchain. A piece of code on the blockchain is used to automatically execute preset verification logic; the second identity information refers to the set of plaintext information that is finally obtained after a series of processing and can be used to identify the second user's identity; the preset mapping relationship rule refers to a data organization specification used to establish and query the correspondence between user identity information and user identity identifier and organization identifier; the mapping relationship refers to the data set stored according to the preset mapping relationship rule, which records the binding relationship between user identity information, user identity identifier and organization identifier; the user identity identifier refers to the internal code used in the system to uniquely identify the user's identity; the organization identifier refers to the code used to uniquely identify an organization; the verification result refers to the final output of the identity validity verification, used to indicate whether the second medical health code is valid.

[0178] The mapping relationship rule is a mapping relationship formed by binding user identity information with user identity identifiers and organization identifiers. Specifically, the mapping relationship rule defines how to associate and store user identity information such as document type code, document number, and name with the user identity identifier generated internally by the system and the organization identifier of the user's organization, forming a record structure that can be quickly retrieved and compared.

[0179] First, in order to provide the time parameters required for the verification of the health code to the blockchain smart contract, a second current timestamp needs to be obtained.

[0180] Regarding this step, in some possible implementations, the system time service interface inside the trusted and secure computing environment can be called to obtain the current Coordinated Universal Time (UTC), convert the time data into a standard timestamp format, and use the obtained timestamp as the second current timestamp.

[0181] Furthermore, the second medical identity identifier, the second signature value, the second user's medical health code generation request summary, and the second current timestamp are input into the blockchain smart contract. The blockchain smart contract verifies the validity of the second signature value and whether the encrypted identity credential corresponding to the second medical identity identifier exists and has not been tampered with.

[0182] Regarding this step, in some possible implementations, a transaction can be constructed using the SDK interface provided by the blockchain node. The input data of this transaction includes a second medical identity identifier, a second signature value, a digest of the second user's medical health code generation request, and a second current timestamp. The transaction is then sent to the blockchain network, triggering the verification function of the blockchain smart contract deployed on the chain. When the blockchain smart contract executes the verification function, it first verifies the second signature value using the public key stored on the chain, then queries the corresponding encrypted identity credential based on the digest of the second user's medical health code generation request, and compares the consistency between the second medical identity identifier and the evidence stored on the chain. Finally, the verification result is returned via a transaction receipt.

[0183] If the blockchain smart contract returns a successful verification, the second identity information needs to be compared with the stored mapping relationship according to the preset mapping relationship rules to determine whether the user identity identifier stored in the mapping relationship matches the second identity information.

[0184] Regarding this step, in some possible implementations, after receiving the verification success notification from the blockchain smart contract, the stored mapping relationship can be loaded from the local database; then, according to the preset mapping relationship rules, the document type code, document number, and name in the second identity information are used as query conditions to search in the mapping relationship to locate the corresponding record; the stored user identity identifier is read from the record and compared with the second identity information to determine whether the two match.

[0185] If the user identity identifier stored in the mapping relationship matches the second identity information, the verification result is determined to be valid.

[0186] Regarding this step, in some possible implementations, if the comparison result shows that the user identity identifier stored in the mapping relationship matches the second identity information, a status code indicating successful verification can be generated. This status code is used as the verification result, indicating that the second medical health code is valid.

[0187] If the user identity identifier stored in the mapping relationship does not match the second identity information, the verification result is determined to be invalid.

[0188] Regarding this step, in some possible implementations, if the comparison result shows that the user identity identifier stored in the mapping relationship is inconsistent with the second identity information, or if no record corresponding to the second identity information is found in the mapping relationship, a status code indicating verification failure can be generated. This status code is used as the verification result, indicating that the second medical health code is invalid.

[0189] In this embodiment, a dual verification mechanism is constructed by combining on-chain verification with off-chain comparison. First, the source, existence, and immutability of the second medical identity are verified using a blockchain smart contract, ensuring the reliability of the on-chain evidence of the health code. Second, after successful on-chain verification, the second identity information is matched and verified through a local mapping relationship, ensuring consistency between the identity information and the system's internal records. This mechanism combines the decentralized trust capability of the blockchain with the efficient query capability of the local system, jointly guaranteeing the accuracy and reliability of identity validity verification. Specifically, the blockchain smart contract verification process confirms the legality and integrity of the second medical health code at the time of its generation, while the comparison of the local mapping relationship further verifies whether the second identity information is a legally authorized identity within the system. The combination of these two processes forms a complete validity verification closed loop.

[0190] In one embodiment, for easier understanding of the cross-level institutional verification and on-chain evidence storage interaction process of the medical health code in this application, please refer to [link to relevant documentation]. Figure 8 , Figure 8 This is a schematic diagram of the interactive architecture for cross-level institutional verification and on-chain evidence storage of medical health codes provided in the embodiments of this application.

[0191] Specifically, this diagram presents the cross-level interactive architecture for medical health code verification and storage, which includes three levels: national-level medical management institutions, provincial-level medical management institutions, and municipal-level medical management institutions, as well as the next-level institutions A (user end) and B (user end) of external institutions. Each level of the national-level, provincial-level, and municipal-level medical management institutions has an authentication terminal and a blockchain terminal, and the authentication terminal and blockchain terminal within the same level are connected sequentially. The next-level institutions A (user end) and B (user end) of external institutions are connected to the authentication terminal of the corresponding level through data security channels.

[0192] The interaction flow of this architecture is as follows: The next-level institution A (user terminal) sends a certificate to the corresponding level of the authentication terminal through a data security channel; the authentication terminal initiates an identifier registration and verification query to the blockchain terminal at the same level; after completing the verification, the blockchain terminal returns spatiotemporal binding information to the authentication terminal; the authentication terminal completes the verification based on this spatiotemporal binding information and returns the verification result to the next-level institution B (user terminal) through the data security channel. Here, the verification operation of the authentication terminal corresponds to the signature verification process performed based on the intrinsic cryptographic service capability in this embodiment; the blockchain terminal corresponds to the functional module that performs blockchain smart contract notarization and spatiotemporal information binding in this embodiment; and the data security channel is used to ensure the security of data transmission between nodes, meeting the security protection requirements of a trusted and secure computing environment.

[0193] In this embodiment, the aforementioned cross-level interactive architecture is adapted to the generation and verification process of the medical health code in this application: the blockchain terminals at each level undertake the spatiotemporal information binding operations based on blockchain smart contracts in this application, realizing on-chain storage and query verification of medical health code-related data; the authentication terminal relies on the intrinsic cryptographic service capability to complete the certificate verification and signature processing, matching the verification requirements for the authenticity and legality of medical health code-related data in this application; the medical management agency architecture at different levels covers medical health code management scenarios in different administrative regions, and the data security channel ensures the security of cross-institutional and cross-level data transmission. The overall architecture supports the secure verification and trusted storage of medical health codes in multi-institutional and multi-level scenarios, which meets the goal of the first medical health code being tamper-proof and traceable.

[0194] In one embodiment, for a better understanding of the entire architecture of this application regarding the construction, generation, parsing, and scenario verification of a trusted and secure computing environment for medical health codes, please refer to [link to relevant documentation]. Figure 9 , Figure 9 This is a schematic diagram of the hierarchical distribution and interaction logic of the medical health code full-process architecture provided in the embodiments of this application.

[0195] Specifically, Figure 9The overall architecture is divided into three levels, with each level, its internal content, and interaction logic as follows: The medical health code scenario verification level includes four interactive steps: user initiates verification to the authentication terminal, authentication terminal initiates verification to the blockchain, blockchain initiates verification to the authentication terminal, and authentication terminal provides feedback to the user. This level ultimately outputs the health code verification result, returning a conclusion of whether it is valid or invalid. The verification operation performed by the authentication terminal corresponds to the signature verification processing based on the intrinsic cryptographic service capability in this application embodiment, and the verification operation performed by the blockchain corresponds to the evidence storage information query and verification processing based on blockchain smart contracts in this application embodiment. The medical health code generation and parsing level, in sequence, covers core steps such as identifier mapping, identifier generation, health code generation rules, a three-layer encryption algorithm architecture, and identifier parsing. The health code generation rules correspond to the relevant rules in this application embodiment for encoding and converting health code generation factor data to obtain the first basic code data. The three-layer encryption algorithm architecture corresponds to the encryption architecture in this application embodiment that performs dynamic masking, dynamic encryption, and signature protection processing based on the first basic code data. Identifier parsing is used to parse the identifier corresponding to the generated medical health code. The trusted secure computing environment is constructed in two core layers: virtual memory encryption and intrinsic cryptographic service capabilities. The virtual memory encryption component encompasses components such as a CSV virtual machine, memory controller, CPU, memory data, encryption, component deployment in a cloud computing environment, and key management. The CSV virtual machine can be a type of secure virtual machine created during the construction of the trusted secure computing environment in this embodiment. The memory controller, in conjunction with encryption operations, performs encryption and decryption of memory data, meeting the technical requirement of real-time encryption of system memory pages under the virtual machine memory encryption capability in this embodiment. Key management corresponds to the management and processing of memory encryption keys in this embodiment. Component deployment in a cloud computing environment provides the runtime support for the trusted secure computing environment. The intrinsic cryptographic service capability component encompasses components such as business interfaces, TKM (PSP), secure storage, CCP national cryptographic engine, and CPU. The business interfaces can correspond to the SDF extension interface provided in this embodiment. The CCP national cryptographic engine can be a type of cryptographic coprocessor built into the CPU in this embodiment, used to provide cryptographic computation services. Secure storage corresponds to the secure storage processing of user keys in this embodiment. The TKM (PSP) supports key management operations related to cryptographic services.

[0196] In this embodiment, the aforementioned end-to-end architecture provides end-to-end security support from the construction of a trusted and secure computing environment to the generation, parsing, and scenario verification of the medical health code. Specifically, the virtual memory encryption function at the trusted and secure computing environment construction level ensures the confidentiality of data storage, while the inherent cryptographic service provides high-performance cryptographic support for subsequent encryption and verification processes. The medical health code generation and parsing level relies on the aforementioned trusted and secure computing environment to complete the standardized generation and identifier parsing of the health code. The medical health code scenario verification level performs legality verification based on the generated medical health code and on-chain evidence information. The coordinated operation of each layer of the overall architecture supports the objectives of confidentiality, integrity, non-forgeability, and traceability of the medical health code in this embodiment.

[0197] Figure 10 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 10 As shown, the electronic device may include: a processor 1301, a communication interface 1302, a memory 1303, and a communication bus 1304, wherein the processor 1301, the communication interface 1302, and the memory 1303 communicate with each other via the communication bus 1304. The processor 1301 can call a computer program in the memory 1303 to execute the steps of the AA method, such as including: Build a trusted and secure computing environment, which includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities; In a trusted and secure computing environment, the initial identity information of the first user is preprocessed and extracted based on the virtual machine memory encryption capability to obtain health code generation factor data. In a trusted and secure computing environment, the health code generation factor data is encoded and converted based on the endogenous cryptographic service capability to obtain the first basic code data. Based on the first basic code data, dynamic masking, dynamic encryption and signature protection are performed to generate the first user's first medical health code.

[0198] Or include: Receive the second user's second medical health code; The second medical health code is transmitted to a trusted secure computing environment, which includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities. In a trusted and secure computing environment, the second medical health code is signed, verified, and decrypted based on the endogenous cryptographic service capability to obtain the second basic code data. Then, the second basic code data is demasked and decoded to obtain the second identity information. The identity validity is verified based on the second identity information, and the verification result is obtained.

[0199] Furthermore, when the logical instructions in the aforementioned memory can be implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0200] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0201] All actions involving the acquisition of signal information or data in this application were carried out in compliance with the relevant data protection laws and policies of the country where the application is located, and with the authorization granted by the owner of the relevant device. Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for generating a medical health code, characterized in that, include: Construct a trusted and secure computing environment, which includes virtual machine memory encryption capabilities and intrinsic cryptographic service capabilities; In the trusted and secure computing environment, the initial identity information of the first user is preprocessed and extracted based on the virtual machine memory encryption capability to obtain health code generation factor data. In the trusted and secure computing environment, the health code generation factor data is encoded and converted based on the intrinsic cryptographic service capability to obtain the first basic code data. Based on the first basic code data, dynamic masking, dynamic encryption, and signature protection are performed to generate the first medical health code for the first user.

2. The method according to claim 1, characterized in that, The construction of the trusted and secure computing environment includes: Configure virtual machine memory encryption capabilities and configure built-in cryptographic service capabilities; Based on the virtual machine memory encryption capability and the intrinsic cryptographic service capability, a trusted and secure computing environment is constructed. The configuration process for the virtual machine memory encryption capability includes: creating a secure virtual machine, which has independent cache and translation backup buffer resources and is isolated from the host and other virtual machines; generating a memory encryption key through the processor, and encrypting the system memory pages of the secure virtual machine in real time based on the memory encryption key, so that plaintext data written to memory is encrypted and stored, and ciphertext data read from memory is decrypted in real time; and managing the memory encryption key through a trusted key management module to ensure that the plaintext of the memory encryption key does not appear in the system memory. The configuration process for the intrinsic cryptographic service capability includes: deploying a trusted platform module in the secure virtual machine; sealing the user key within the trusted platform module using its data sealing function; setting the expected value and authorization code of the platform configuration register; providing cryptographic computation services through the cryptographic coprocessor built into the CPU, the cryptographic computation services including at least one of the SM2 algorithm, SM3 algorithm, SM4 algorithm, and a true random number generator; and providing an SDF extension interface through the business interface, the SDF extension interface being used to call the cryptographic coprocessor to perform cryptographic computations.

3. The method according to claim 1, characterized in that, In the trusted and secure computing environment, based on the virtual machine memory encryption capability, the initial identity information of the first user is preprocessed and extracted to obtain health code generation factor data, including: In the trusted and secure computing environment, based on the virtual machine memory encryption capability, the document type code, document number, name, regional factor and reserved control factor in the initial identity information of the first user are standardized to obtain standardized identity information; The standardized identity information is converted according to the UTF-8 encoding format to obtain a UTF-8 encoded string; Extract a specified number of bytes from the UTF-8 encoded string to serve as the health code generation factor data.

4. The method according to claim 1, characterized in that, In the trusted and secure computing environment, the health code generation factor data is encoded and converted based on the intrinsic cryptographic service capability to obtain first basic code data. Then, dynamic masking, dynamic encryption, and signature protection are performed on the first basic code data to generate the first user's first medical health code, including: In the trusted and secure computing environment, the document type code, document number and name in the health code generation factor data are converted and concatenated to obtain the original data string; The first check code is determined based on the original data string, and the first check code is appended to the end of the original data string to obtain the first basic code data. Based on the first verification code, a corresponding random number is selected from a preset mask library as the first HMAC key; Based on the intrinsic cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the first basic code data and the first HMAC key to obtain the first protected identity code. The first protected identity code is concatenated with the first organization identifier corresponding to the first user to obtain the first intermediate concatenated data; A first dynamic identifier is generated based on the first check code, and a first initial vector is selected from the mask library based on the first dynamic identifier; Based on the intrinsic cryptographic service capability, the SM4 algorithm is invoked, and the first intermediate concatenated data is encrypted using CBC mode, the group key corresponding to the first organization identifier, and the first initial vector to obtain the first encrypted data. The first encrypted data is concatenated with the first dynamic identifier to obtain the first medical identity identifier; Based on the intrinsic cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the first institution identifier is used to digitally sign the first medical identity identifier to obtain the first signature value. Based on a blockchain smart contract, the first encrypted identity credential is generated by binding the first medical identity identifier, the first signature value, and the medical health code generation request digest of the first user with the spatiotemporal information of the execution time and space. The first user's first medical health code is generated based on the first encrypted identity credential.

5. The method according to claim 4, characterized in that, The first encrypted data is obtained by invoking the SM4 algorithm based on the intrinsic cryptographic service capability, using CBC mode, the group key corresponding to the first organization identifier, and the first initialization vector to encrypt the first intermediate concatenated data, including: Based on the group key corresponding to the first organization identifier and the first initial vector, the first intermediate concatenated data is padded with PKCS7 to obtain the padded first intermediate concatenated data, which meets the block length requirements of the SM4 algorithm. The first intermediate spliced ​​data after filling is divided into multiple data blocks according to the group size; Based on the intrinsic cryptographic service capability, the SM4-based encryption operation is performed on each of the multiple data blocks in the CBC mode to obtain the ciphertext block corresponding to each of the multiple data blocks; The ciphertext block corresponding to the first data block among the plurality of data blocks is obtained by encrypting the first data block and the first initial vector by performing an XOR operation; the ciphertext block corresponding to the data block after the first data block is obtained by encrypting the data block after the first data block and the previous ciphertext block by performing an XOR operation. The ciphertext blocks corresponding to each of the multiple data blocks are concatenated in sequence to obtain the first encrypted data.

6. The method according to claim 4, characterized in that, The step of invoking the SM2 algorithm based on the intrinsic cryptographic service capability, using the platform key corresponding to the first institution identifier to digitally sign the first medical identity identifier, and obtaining a first signature value includes: The SDF extension interface based on the intrinsic cryptographic service capability inputs the first medical identity identifier to the cryptographic coprocessor; Inside the cryptographic coprocessor, the security processor and the key coprocessor use the platform key corresponding to the first institution identifier to perform a signature operation based on the SM2 algorithm on the first medical identity identifier to obtain the first signature value.

7. The method according to claim 4, characterized in that, The first encrypted identity credential is generated by binding the first medical identity identifier, the first signature value, and the medical health code generation request digest of the first user with the spatiotemporal information of the blockchain smart contract, including: Get the first current timestamp; The first medical identity identifier, the first signature value, the first user's medical health code generation request summary, and the first current timestamp are input into the blockchain smart contract as binding parameters. The first signature value is verified through the blockchain smart contract to obtain a first verification result; If the first verification result indicates that the verification is successful, the first medical identity identifier, the timestamp, and the first user's medical health code generation request digest are stored on-chain in a privacy-preserving manner through the blockchain smart contract to generate the first encrypted identity credential.

8. A method for verifying a medical health code, characterized in that, include: Receive the second user's second medical health code; The second medical health code is transmitted to the trusted secure computing environment according to any one of claims 1 to 7, wherein the trusted secure computing environment includes virtual machine memory encryption capability and intrinsic cryptographic service capability; In the trusted and secure computing environment, the second medical health code is subjected to signature verification and decryption processing based on the endogenous cryptographic service capability to obtain the second basic code data. Then, the second basic code data is subjected to demasking and decoding conversion processing to obtain the second identity information. The identity validity is verified based on the second identity information, and the verification result is obtained.

9. The method according to claim 8, characterized in that, In the trusted and secure computing environment, the second medical health code is subjected to signature verification and decryption processing based on the intrinsic cryptographic service capability to obtain second basic code data. Then, based on the second basic code data, demasking and decoding conversion processing are performed to obtain second identity information, including: In the trusted and secure computing environment, the second medical identity identifier and the corresponding second signature value are parsed from the second medical health code; Based on the intrinsic cryptographic service capability, the SM2 algorithm is invoked, and the platform key corresponding to the second institution identifier is used to perform signature verification on the second medical identity identifier to obtain the second verification result; If the second verification result indicates that the verification is successful, the second dynamic identifier and the encrypted part are separated from the second medical identity identifier, and the corresponding second initial vector is selected from the preset mask library based on the second dynamic identifier; Based on the intrinsic cryptographic service capability, the SM4 algorithm is invoked, and the encrypted part is decrypted using CBC mode, the group key corresponding to the second organization identifier, and the second initial vector to obtain the decrypted second intermediate concatenation data. The second protected identity code and the second basic code data are separated from the decrypted second intermediate spliced ​​data; The second dynamic identifier is used to select a corresponding random number from a preset mask library as the second HMAC key; Based on the intrinsic cryptographic service capability, the SM3 algorithm is invoked to perform HMAC-SM3 calculation on the second basic code data and the second HMAC key to obtain the identity code to be verified. The identity code to be verified is compared with the second protected identity code to verify data integrity; If the integrity verification passes, the second basic code data is decoded into UTF-8 to obtain the second user's ID type code, ID number, and name; The second identity information is determined based on the second user's ID type code, ID number, and name, as well as the second organization identifier in the decrypted second intermediate concatenation data.

10. The method according to claim 9, characterized in that, The step of verifying the identity validity based on the second identity information to obtain the verification result includes: Get the second current timestamp; The second medical identity identifier, the second signature value, the medical health code generation request digest of the second user, and the second current timestamp are input into the blockchain smart contract. The blockchain smart contract verifies the validity of the second signature value and whether the encrypted identity certificate corresponding to the second medical identity identifier exists and has not been tampered with. If the blockchain smart contract returns a successful verification, the second identity information is compared with the stored mapping relationship according to the preset mapping relationship rules to determine whether the user identity identifier stored in the mapping relationship matches the second identity information. If the user identity identifier stored in the mapping relationship matches the second identity information, the verification result is determined to be valid; If the user identity identifier stored in the mapping relationship does not match the second identity information, the verification result is determined to be invalid. The mapping relationship rule is a mapping relationship formed by binding user identity information with user identity identifiers and organization identifiers.

Images