Identity binding confirmation code based anti-skip verification key encapsulation method and device

Abstract

The application provides an anti-skip verification key encapsulation method and device based on an identity binding confirmation code, which comprises the following steps: a second device performs a decryption operation on a first ciphertext parameter based on a private key to obtain a second target character sequence; the second target character sequence is encrypted based on a public key to obtain a second ciphertext parameter; if the second ciphertext parameter is different from the first ciphertext parameter, the second device determines that the key encapsulation verification of the second device fails; if the second ciphertext parameter is the same as the first ciphertext parameter, the second device generates a second identity binding confirmation code based on the second target character sequence and the identity of the second device; if the second identity binding confirmation code is different from a first identity binding confirmation code, the second device determines that the key encapsulation verification fails; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the second device determines that the key encapsulation verification succeeds. Through the technical scheme of the application, the safety of data can be ensured.

Description

Technical Field

[0001] This application relates to the fields of cryptography and information security technology, and in particular to a method and apparatus for encapsulating anti-skipped verification keys based on identity binding confirmation codes. Background Technology

[0002] Key Encapsulation Mechanism (KEM) is a cryptographic protocol for securely exchanging encryption keys. It comprises two processes: encapsulation and decapsulation. During encapsulation, an encrypted ciphertext and a shared key are generated. During decapsulation, the same shared key is recovered from the ciphertext using a private key.

[0003] To achieve Adaptive Choice-Ciphertext Attack Security (IND-CCA), the Fujisaki-Okamoto (FO) transformation is employed as a general method for constructing key encapsulation mechanisms. The FO transformation elevates encryption schemes that only meet the requirements of Choice-Plaintext Attack Security (IND-CPA) to the IND-CCA security level by introducing a "de-randomization" mechanism and a "re-encryption check" step. Within the FO transformation framework, the sender encrypts a random message using the receiver's public key and derives a shared key. During decapsulation, the receiver needs to re-encrypt, generating new ciphertext and comparing it with the original ciphertext to verify the correctness of the decryption process. This "re-encryption check" mechanism is a crucial step in ensuring the security of the key encapsulation mechanism.

[0004] However, in actual engineering implementation, due to reasons such as code logic errors, improper exception handling, or human negligence, the "re-encryption check" step may be bypassed or skipped, thereby compromising the overall security. Summary of the Invention

[0005] This application provides a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code, applied to a system including a first device and a second device, the method comprising:

[0006] The first device generates a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device; it encrypts the first target character sequence based on the acquired public key of the second device to obtain a first ciphertext parameter; and it sends a first message to the second device, the first message including the first identity binding confirmation code and the first ciphertext parameter.

[0007] The second device decrypts the first ciphertext parameter using its private key to obtain a second target character sequence; it then encrypts the second target character sequence using its public key to obtain a second ciphertext parameter; if the second ciphertext parameter is different from the first ciphertext parameter, the key encapsulation verification of the second device is determined to have failed.

[0008] If the second ciphertext parameter is the same as the first ciphertext parameter, the second device generates a second identity binding confirmation code based on the second target character sequence and the identity identifier of the second device;

[0009] If the second identity binding confirmation code is different from the first identity binding confirmation code, the second device determines that the key encapsulation verification has failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the second device determines that the key encapsulation verification has succeeded.

[0010] This application provides a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code, applied to a first device in a system, the system further including a second device, the method comprising:

[0011] A first identity binding confirmation code is generated based on the acquired first target character sequence and the identity identifier of the second device; wherein, the first target character sequence is obtained by the first device selecting characters from a pre-generated string set, and the identity identifier represents the user's identity identifier;

[0012] The first target character sequence is encrypted using the obtained public key of the second device to obtain the first ciphertext parameter; wherein the public key is generated by the second device in a trusted execution environment;

[0013] Send a first message to the second device, the first message including the first identity binding confirmation code and the first ciphertext parameter; so that the second device determines whether the key encapsulation verification of the second device has failed or succeeded based on the first identity binding confirmation code and the first ciphertext parameter.

[0014] This application provides a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code, applied to a second device in a system, the system further including a first device, the method comprising:

[0015] The system receives a first message sent by a first device, the first message including a first identity binding confirmation code and a first ciphertext parameter; wherein, the first identity binding confirmation code is generated by the first device based on an acquired first target character sequence and the identity identifier of the second device, and the first ciphertext parameter is obtained by the first device encrypting the first target character sequence based on the public key of the second device;

[0016] The first ciphertext parameter is decrypted using the private key of the second device to obtain the second target character sequence; the second target character sequence is encrypted using the public key of the second device to obtain the second ciphertext parameter; if the second ciphertext parameter is different from the first ciphertext parameter, the key encapsulation verification of the second device is determined to have failed; if the second ciphertext parameter is the same as the first ciphertext parameter, a second identity binding confirmation code is generated based on the second target character sequence and the identity identifier of the second device.

[0017] If the second identity binding confirmation code is different from the first identity binding confirmation code, the key encapsulation verification of the second device is determined to have failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the key encapsulation verification of the second device is determined to have succeeded.

[0018] This application provides an anti-skip verification key encapsulation device based on an identity binding confirmation code, applied to a first device in a system, the system further including a second device, the device comprising:

[0019] The generation module is used to generate a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device; wherein, the first target character sequence is obtained by the first device selecting characters from the generated string set, and the identity identifier represents the user's identity identifier;

[0020] The processing module is used to perform an encryption operation on the first target character sequence based on the obtained public key of the second device to obtain the first ciphertext parameter corresponding to the first target character sequence; wherein, the public key of the second device is generated by the second device in a trusted execution environment;

[0021] The sending module is configured to send a first message to the second device, the first message including the first identity binding confirmation code and the first ciphertext parameter; so that the second device determines whether the key encapsulation verification failed or succeeded based on the first identity binding confirmation code and the first ciphertext parameter.

[0022] This application provides an anti-skip verification key encapsulation device based on an identity binding confirmation code, applied to a second device in a system. The system further includes a first device, and the device includes:

[0023] The receiving module is used to receive a first message sent by the first device. The first message includes a first identity binding confirmation code and a first ciphertext parameter. The first identity binding confirmation code is generated by the first device based on a first target character sequence and the identity identifier of the second device. The first ciphertext parameter is obtained by the first device encrypting the first target character sequence based on the public key of the second device.

[0024] The processing module is configured to decrypt the first ciphertext parameter based on the private key of the second device to obtain a second target character sequence; and encrypt the second target character sequence based on the public key of the second device to obtain a second ciphertext parameter.

[0025] The determination module is configured to: if the second ciphertext parameter is different from the first ciphertext parameter, determine that the key encapsulation verification of the second device has failed; if the second ciphertext parameter is the same as the first ciphertext parameter, generate a second identity binding confirmation code based on the second target character sequence and the identity identifier of the second device; if the second identity binding confirmation code is different from the first identity binding confirmation code, determine that the key encapsulation verification of the second device has failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, determine that the key encapsulation verification of the second device has succeeded.

[0026] This application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described anti-skip verification key encapsulation method based on identity binding confirmation code.

[0027] This application provides an electronic device, including: a processor and a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions that can be executed by the processor; wherein the processor is used to execute the machine-executable instructions to implement the above-described anti-skip verification key encapsulation method based on identity binding confirmation code.

[0028] This application provides a machine-readable storage medium storing machine-executable instructions that can be executed by a processor; wherein the processor is used to execute the machine-executable instructions to implement the above-described method for anti-skip verification key encapsulation based on identity binding confirmation code.

[0029] As can be seen from the above technical solution, in this embodiment, the second device decrypts the first ciphertext parameter using its private key to obtain a second target character sequence, and encrypts the second target character sequence using its public key to obtain a second ciphertext parameter. If the second ciphertext parameter is different from the first ciphertext parameter, the key encapsulation verification fails; if the second ciphertext parameter is the same as the first ciphertext parameter, a second identity binding confirmation code is generated based on the second target character sequence and the identity identifier of the second device; if the second identity binding confirmation code is different from the first identity binding confirmation code, the key encapsulation verification fails; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the key encapsulation verification succeeds.

[0030] If the second identity binding confirmation code is the same as the first identity binding confirmation code, then the second device has definitely performed a "re-encryption check" and confirmed that the key encapsulation verification was successful. Successful key encapsulation verification indicates successful identity authentication. If the second identity binding confirmation code is different from the first identity binding confirmation code, or the second ciphertext parameter is different from the first ciphertext parameter, then the second device has also performed a "re-encryption check," but confirmed that the key encapsulation verification failed. Failed key encapsulation verification indicates unsuccessful identity authentication. The re-encryption check involves the second device encrypting the second target character sequence based on its public key to obtain the second ciphertext parameter, and comparing the second ciphertext parameter with the first ciphertext parameter. Thus, during the decapsulation process, the second device (the receiver) will re-execute the encryption operation, generating a new ciphertext (the second ciphertext parameter) and comparing it with the original ciphertext (the first ciphertext parameter) to verify the correctness of the decryption process, thereby determining whether identity authentication was successful. Based on the above process, if the key encapsulation verification is successful, subsequent encryption and decryption processes can be executed; if the key encapsulation verification fails, subsequent encryption and decryption processes must be prohibited to ensure data security.

[0031] In summary, this application proposes an identity-binding key encapsulation mechanism based on an identity-binding verification code. While retaining the advantages of FO transformation, it introduces additional identity-binding verification code generation and verification steps, forming a dual verification mechanism. This enhances the system's resistance to implementation vulnerabilities, enables implicit identity authentication, strengthens system security, prevents security failures caused by bypassing the verification process, and improves the security and robustness of the key encapsulation mechanism in a post-quantum environment. Without significantly increasing communication overhead, it enhances resistance to impersonation attacks and prevents code logic vulnerabilities. Attached Figure Description

[0032] Figure 1A This is a flowchart illustrating a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code.

[0033] Figure 1B This is a flowchart illustrating a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code.

[0034] Figure 1C This is a flowchart illustrating a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code.

[0035] Figure 2 This is a flowchart illustrating a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code.

[0036] Figure 3A This is a schematic diagram of a key encapsulation device for preventing skipped verification based on an identity binding confirmation code;

[0037] Figure 3BThis is a schematic diagram of a key encapsulation device for preventing skipped verification based on an identity binding confirmation code;

[0038] Figure 4 This is a hardware structure diagram of an electronic device according to one embodiment of this application. Detailed Implementation

[0039] This application proposes a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code. This method can be applied to a system including a first device and a second device. See also Figure 1A The diagram shows a flowchart of a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code. This method may include:

[0040] Step 101: The first device generates a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device; the first device encrypts the first target character sequence based on the acquired public key of the second device to obtain a first ciphertext parameter; the first device sends a first message to the second device, which may include the first identity binding confirmation code and the first ciphertext parameter.

[0041] Step 102: The second device decrypts the first ciphertext parameter based on its private key to obtain the second target character sequence; the second device encrypts the second target character sequence based on its public key (which can be paired with the private key) to obtain the second ciphertext parameter.

[0042] Step 103: The second device determines whether the second ciphertext parameter is different from the first ciphertext parameter.

[0043] If so, that is, the second ciphertext parameter is different from the first ciphertext parameter, then proceed to step 104;

[0044] If not, that is, the second ciphertext parameter is the same as the first ciphertext parameter, then proceed to step 105.

[0045] Step 104: The second device determines that the key encapsulation verification of the second device has failed.

[0046] Step 105: The second device generates a second identity binding confirmation code based on the second target character sequence and the identity identifier of the second device, and determines whether the second identity binding confirmation code is different from the first identity binding confirmation code.

[0047] If so, that is, the second identity binding confirmation code is different from the first identity binding confirmation code, then proceed to step 106;

[0048] If not, i.e. the second identity binding confirmation code is the same as the first identity binding confirmation code, then proceed to step 107.

[0049] Step 106: The second device determines that the key encapsulation verification failed.

[0050] Step 107: The second device confirms that the key encapsulation verification was successful.

[0051] For example, the first device generates a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device, which may include, but is not limited to: the first device generating the first identity binding confirmation code based on the first target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and a random number of the second device; wherein, the first target character sequence is obtained by the first device selecting characters from a pre-generated string set, the identity identifier represents the user's identity identifier, the device fingerprint represents the unique device identifier of the second device, and the random number is randomly generated by the second device; wherein, the first target character sequence, the identity identifier, the device fingerprint, and the random number are combined to obtain context information; a quantum-resistant hash operation is performed on the context information to obtain an intermediate value confirmation code of a specified length; the first target character sequence is used as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the first identity binding confirmation code.

[0052] For example, before the first device encrypts the first target character sequence based on the obtained public key of the second device to obtain the first ciphertext parameter, the second device generates a private key and a public key paired with the private key, maps the public key to a confused public key, the public key being a lattice-based public key, and the confused public key being a random string; the second device sends a second message to the first device; wherein the second message includes an invalid random string and a confused public key indistinguishable from the invalid random string; based on the position information of the confused public key in the second message, the first device parses the confused public key from the second message and maps the confused public key to the public key of the second device.

[0053] For example, the second device includes a trusted execution environment and a rich execution environment. The trusted execution environment is a secure execution area isolated from the operating system and protected by hardware. The rich execution environment is an open environment running the operating system. The trusted execution environment is isolated from the rich execution environment. When generating a private key and a public key that is paired with the private key, the second device generates the private key and public key in the trusted execution environment and prohibits the private key from leaving the trusted execution environment.

[0054] For example, the first device performs an encryption operation on the first target character sequence based on the public key of the second device to obtain the first ciphertext parameter, which may include, but is not limited to: the first device performs a key derivation operation on the first target character sequence to obtain the random number required for encryption, and uses the public key of the second device to perform an encryption operation on the first target character sequence and the random number to obtain the first ciphertext parameter.

[0055] For example, the second device performs an encryption operation on the second target character sequence based on the public key of the second device to obtain the second ciphertext parameter, which may include, but is not limited to: the second device performs a key derivation operation on the second target character sequence to obtain the random number required for encryption, and uses the public key of the second device to encrypt the second target character sequence and the random number to obtain the second ciphertext parameter.

[0056] For example, after the second device determines that the key encapsulation verification is successful, the second device performs a key derivation operation on the second target character sequence to obtain a target shared key; the second device performs encryption or decryption operations on the application data exchanged between the first device and the second device based on the target shared key; the first device performs a key derivation operation on the first target character sequence to obtain a target shared key; the first device performs encryption or decryption operations on the application data exchanged between the first device and the second device based on the target shared key.

[0057] This application proposes a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code. This method can be applied to a first device in the system. The system also includes a second device (see [link]). Figure 1B The diagram shows a flowchart of a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code. This method may include:

[0058] Step 111: Generate a first identity binding confirmation code based on the obtained first target character sequence and the identity identifier of the second device; wherein, the first target character sequence is obtained by the first device selecting characters from the generated string set, and the identity identifier represents the user's identity identifier.

[0059] Step 112: Encrypt the first target character sequence based on the obtained public key of the second device to obtain the first ciphertext parameter; wherein, the public key is generated by the second device in a trusted execution environment.

[0060] Step 113: Send a first message to the second device, which may include a first identity binding confirmation code and a first ciphertext parameter; so that the second device can determine whether the key encapsulation verification of the second device has failed or succeeded based on the first identity binding confirmation code and the first ciphertext parameter.

[0061] For example, generating a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device may include, but is not limited to: generating the first identity binding confirmation code based on the first target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and a random number of the second device; wherein, the first target character sequence may be obtained by the first device selecting characters from a pre-generated string set, the identity identifier may represent the user's identity identifier, the device fingerprint may represent the unique device identifier of the second device, and the random number may be randomly generated by the second device; wherein, the first target character sequence, the identity identifier, the device fingerprint, and the random number are combined to obtain context information; a quantum-resistant hash operation is performed on the context information to obtain an intermediate value confirmation code of a specified length; and the first target character sequence is used as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the first identity binding confirmation code.

[0062] For example, the encryption operation on the first target character sequence based on the obtained public key of the second device to obtain the first ciphertext parameter may include, but is not limited to: performing a key derivation operation on the first target character sequence to obtain the random number required for encryption, and using the public key of the second device to encrypt the first target character sequence and the random number to obtain the first ciphertext parameter.

[0063] This application proposes an anti-skip verification key encapsulation method based on identity binding confirmation codes, which can be applied to the second device in the system. The system also includes a first device, see [link to relevant documentation]. Figure 1C The diagram shows a flowchart of a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code. This method may include:

[0064] Step 121: Receive a first message sent by the first device. The first message may include a first identity binding confirmation code and a first ciphertext parameter. The first identity binding confirmation code may be generated by the first device based on the first target character sequence and the identity identifier of the second device. The first ciphertext parameter may be obtained by the first device encrypting the first target character sequence based on the public key of the second device.

[0065] Step 122: Decrypt the first ciphertext parameter using the private key of the second device to obtain the second target character sequence; encrypt the second target character sequence using the public key of the second device to obtain the second ciphertext parameter.

[0066] Step 123: If the second ciphertext parameter is different from the first ciphertext parameter, the key encapsulation verification of the second device is determined to have failed; if the second ciphertext parameter is the same as the first ciphertext parameter, a second identity binding confirmation code is generated based on the second target character sequence and the identity identifier of the second device. If the second identity binding confirmation code is different from the first identity binding confirmation code, the key encapsulation verification of the second device is determined to have failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the key encapsulation verification of the second device is determined to have succeeded.

[0067] For example, generating a second identity binding confirmation code based on a second target character sequence and the identity identifier of a second device may include, but is not limited to: generating a second identity binding confirmation code based on a second target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and a random number of the second device; wherein, the second target character sequence may be obtained by the second device selecting characters from a pre-generated string set, the identity identifier may represent the user's identity identifier, the device fingerprint may represent the unique device identifier of the second device, and the random number may be randomly generated by the second device; wherein, the second target character sequence, the identity identifier, the device fingerprint, and the random number are combined to obtain context information; a quantum-resistant hash operation is performed on the context information to obtain an intermediate value confirmation code of a specified length; the second target character sequence is used as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the second identity binding confirmation code.

[0068] For example, a private key and a public key paired with the private key can be generated for the second device. The public key is then mapped to a confused public key, where the public key is a lattice-based public key and the confused public key is a random string. A second message is then sent to the first device; the second message may include an invalid random string and a confused public key indistinguishable from the invalid random string; and based on the position information of the confused public key in the second message, the first device parses the confused public key from the second message and maps it to the public key of the second device.

[0069] For example, the second device includes a trusted execution environment and a rich execution environment. The trusted execution environment is a secure execution area that is isolated from the operating system and protected by hardware. The rich execution environment is an open environment that runs the operating system. The trusted execution environment is isolated from the rich execution environment. When generating a private key and a public key that is paired with the private key, the private key and the public key are generated in the trusted execution environment, and the private key is prohibited from leaving the trusted execution environment.

[0070] For example, the second device performs an encryption operation on the second target character sequence based on the public key of the second device to obtain the second ciphertext parameter, which may include, but is not limited to: the second device performs a key derivation operation on the second target character sequence to obtain the random number required for encryption, and uses the public key of the second device to encrypt the second target character sequence and the random number to obtain the second ciphertext parameter.

[0071] As can be seen from the above technical solution, in this embodiment, the second device decrypts the first ciphertext parameter using its private key to obtain a second target character sequence, and encrypts the second target character sequence using its public key to obtain a second ciphertext parameter. If the second ciphertext parameter is different from the first ciphertext parameter, the key encapsulation verification fails; if the second ciphertext parameter is the same as the first ciphertext parameter, a second identity binding confirmation code is generated based on the second target character sequence and the identity identifier of the second device; if the second identity binding confirmation code is different from the first identity binding confirmation code, the key encapsulation verification fails; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the key encapsulation verification succeeds.

[0072] If the second identity binding confirmation code is the same as the first identity binding confirmation code, then the second device has definitely performed a "re-encryption check" and confirmed that the key encapsulation verification was successful. Successful key encapsulation verification indicates successful identity authentication. If the second identity binding confirmation code is different from the first identity binding confirmation code, or the second ciphertext parameter is different from the first ciphertext parameter, then the second device has also performed a "re-encryption check," but confirmed that the key encapsulation verification failed. Failed key encapsulation verification indicates unsuccessful identity authentication. The re-encryption check involves the second device encrypting the second target character sequence based on its public key to obtain the second ciphertext parameter, and comparing the second ciphertext parameter with the first ciphertext parameter. Thus, during the decapsulation process, the second device (the receiver) will re-execute the encryption operation, generating a new ciphertext (the second ciphertext parameter) and comparing it with the original ciphertext (the first ciphertext parameter) to verify the correctness of the decryption process, thereby determining whether identity authentication was successful. Based on the above process, if the key encapsulation verification is successful, subsequent encryption and decryption processes can be executed; if the key encapsulation verification fails, subsequent encryption and decryption processes must be prohibited to ensure data security.

[0073] In summary, this application proposes an identity-binding key encapsulation mechanism based on an identity-binding verification code. While retaining the advantages of FO transformation, it introduces additional identity-binding verification code generation and verification steps, forming a dual verification mechanism. This enhances the system's resistance to implementation vulnerabilities, enables implicit identity authentication, strengthens system security, prevents security failures caused by bypassing the verification process, and improves the security and robustness of the key encapsulation mechanism in a post-quantum environment. Without significantly increasing communication overhead, it enhances resistance to impersonation attacks and prevents code logic vulnerabilities.

[0074] The technical solutions described above in the embodiments of this application will be explained below in conjunction with specific application scenarios.

[0075] Key encapsulation mechanisms can include encapsulation and decapsulation. During encapsulation, an encrypted ciphertext and a shared key are generated. During decapsulation, the same shared key is recovered from the ciphertext using a private key. The Fork-of-Flight (FO) transform, as a general method for constructing key encapsulation mechanisms, introduces a "de-randomization" mechanism and a "re-encryption check" step to enhance security. Within the FO transform framework, the sender encrypts a random message using the receiver's public key and derives a shared key. During decapsulation, the receiver needs to re-encrypt the message, generating new ciphertext and comparing it with the original ciphertext to verify the decryption process. However, in practical engineering implementations, due to code logic errors, improper exception handling, or human negligence, the "re-encryption check" step may be bypassed or skipped, compromising overall security and allowing attackers to obtain the shared key by forging ciphertext, seriously threatening communication security.

[0076] To address the aforementioned findings, this application proposes a key encapsulation method based on an identity-bound confirmation code to resist bypassed verification. This method is an Identity Bound Confirmation Code Enhanced Key Encapsulation Mechanism (IB-CC-KEM). In this embodiment, an additional identity-bound confirmation code generation and verification step is introduced into the FO transformation, forming a dual verification mechanism. During the encapsulation phase, the sender generates a confirmation code based on the message and the receiver's identity identifier. During the decapsulation phase, the receiver recalculates the confirmation code and compares it with the original value; if they do not match, the shared key is rejected. By introducing the identity-bound confirmation code mechanism, not only is the system's resistance to implementation vulnerabilities enhanced, but implicit identity authentication is also implemented, effectively preventing impersonation attacks and security risks associated with bypassing the verification process, thus improving the security and robustness of the key encapsulation mechanism in a post-quantum environment.

[0077] This application proposes a method for encapsulating a key that resists skipped verification based on an identity binding confirmation code. This method can be applied to any system, which may include a first device and a second device. The first device may be a sending device, and the second device may be a receiving device, or the first device may be a receiving device, and the second device may be a sending device. This embodiment does not impose any restrictions on this. For example, in subsequent embodiments, the first device will be the sending device, and the second device will be the receiving device.

[0078] For example, this method can be applied to Internet of Things (IoT) systems, which can include clients and servers. The first device can be a client, and the second device can be a server, or vice versa. For instance, in an IoT system, the client can be an IoT device or an edge computing terminal with lightweight computing capabilities. IoT devices can be such as smart home devices, industrial control equipment, or medical devices. Clients can also be other types of devices, such as personal computers, smartphones, or laptops. The server can be a cloud server or a gateway node, responsible for handling key encapsulation verification and key negotiation for the client.

[0079] See Figure 2 The diagram shown is a flowchart of the method, which may include:

[0080] Step 201: The second device generates a private key and a public key. There are no restrictions on how the public and private keys are generated. For example, the second device can use a key generation algorithm to generate the public key. and private key .

[0081] For example, key generation algorithms The input can be security parameters. Key generation algorithm The output can be a public key. and private key Regarding this key generation algorithm Without restrictions, based on this, the security parameters are... After substituting the keys, you can obtain the public key. and private key .

[0082] Regarding safety parameters Safety parameters can be determined based on safety requirements. The number of bits, for example, if the security requirement is greater, then the security parameters... The more bits a parameter has, the lower the security requirement will be. The fewer the number of bits, the better. Based on security parameters. Given the number of bits, a random number of that number of bits can be generated (e.g., using a sampling algorithm to generate a random number of that number of bits), and this random number can be used as a security parameter. For example, taking 256-bit as an example, it is possible to generate 256-bit security parameters. Security parameters Recorded as .

[0083] For example, the second device may include a Trusted Execution Environment (TEE) and a Rich Execution Environment (REE). The TEE can be a secure execution region isolated from the operating system and protected by hardware. Conversely, the REE can be an open environment running an operating system, isolated from the TEE. For instance, as a hardware-level security technology, the TEE provides confidentiality, integrity, and verifiability guarantees for the execution of sensitive data and code by building a secure region (secure execution region) isolated from the operating system on the processor and using hardware mechanisms (such as memory encryption and access control). TEEs have been applied in high-security scenarios such as mobile payments and biometric authentication. The REE is an open environment running a general-purpose operating system (such as Linux), responsible for handling regular applications and network communications.

[0084] Based on this, in this embodiment, the second device generates the public key. and private key At that time, the second device generates a public key in a trusted execution environment. and private key And prohibit private keys Leaving the trusted execution environment, i.e., the private key The private key is permanently and securely stored within a Trusted Execution Environment (TEE) and never exported. The TEE is a hardware-supported, independent, secure region strictly isolated from the rich execution environment running a general-purpose operating system. This allows for the secure storage of the private key for a second device. To avoid using the private key of a second device A leak has occurred.

[0085] Step 202: The second device maps the public key to a confused public key and sends a second message to the first device. The second message includes an invalid random string and a confused public key indistinguishable from the invalid random string. Alternatively, the second device sends a second message to the first device, which only includes the confused public key. In this way, after receiving the second message, the first device can directly parse the confused public key from it.

[0086] For example, public key It is a public key based on lattice cryptography (such as ML-KEM / Kyber, etc.), obfuscating the public key. It is a random string, such as a uniformly random byte string. The second device obtains the public key. After that, instead of the public key... Instead of sending it to the first device, the obfuscated public key is sent. Send to the first device.

[0087] For example, a cryptographic sub-encoding technique can be designed to encode the public key based on lattice cryptography. The string is mapped to a uniformly random byte string, and this mapped random string is used as the obfuscation public key. In this way, the public key Mapped to obfuscated public key Regarding how to map public keys To obfuscate the public key This embodiment does not impose any restrictions on obfuscating the public key. It can be a random string. For example, a public key that satisfies a specific algebraic structure. The encoding is a string s that is statistically indistinguishable from a uniformly random string in {0, 1}^{|x|}, and this string s is used as the obfuscation public key. .

[0088] For example, due to the confusion of public keys It is a random string, i.e., a confuse public key. Indistinguishable from the random string, the second message sent by the second device to the first device includes an invalid random string and a confused public key indistinguishable from the invalid random string. This design not only provides post-quantum security, but also effectively obfuscates communication traffic, resisting network censorship based on traffic analysis.

[0089] For example, the first a1 bytes of the second message are an invalid random string (such as a randomly generated string, this part of the string is invalid data), and the middle a2 bytes are the obfuscated public key. The following 'a3' bytes are invalid random strings. Clearly, after receiving the second message, the attacker obfuscated the public key. It is indistinguishable from an invalid random string; therefore, it is impossible to determine which bytes constitute the obfuscated public key. Therefore, it is impossible to resolve the obfuscated public key. Therefore, the public key cannot be obtained. .

[0090] Step 203: The first device receives the second message. Based on the location information of the obfuscated public key in the second message, the first device parses the obfuscated public key from the second message and maps the obfuscated public key to the public key of the second device.

[0091] For example, the first device is aware of obfuscating the public key. The location information in the second message (which the attacker cannot know), such as the location information indicating that starting from a certain byte, consecutive 'a2' bytes are the obfuscated public key. In this way, the first device can parse the obfuscated public key from the second message. .

[0092] After obtaining the obfuscated public key After obtaining the random string, the obfuscated public key can be... Mapped to public keys based on lattice cryptography (such as ML-KEM / Kyber, etc.). For example, design a cryptographic sub-decoding technique that can obfuscate a uniformly random string of bytes (i.e., a public key). Mapped to a lattice-based public key This allows us to obtain the public key of the second device. .

[0093] Step 204: The first device obtains the first target character sequence (also known as message m), the identity identifier of the second device, the device fingerprint of the second device, and the random number of the second device.

[0094] The first target character sequence is obtained by the first device selecting characters from a string set. For example, the first device can pre-configure a string set, which may include n characters, such as 1024 characters. Based on this, the first device can randomly select m characters from the string set (e.g., randomly selecting one character at a time for a total of m characters, or randomly selecting a position and selecting m characters consecutively from that position, without restriction). m can be less than n, such as 256 characters, and the randomly selected m characters are used to form the first target character sequence.

[0095] For example, n characters can be n numerical values ​​(such as the binary values ​​of 0 and 1). For example, a string set can also be denoted as a bit string set {0, 1}^n, which includes n binary numerical values ​​composed of 0 and 1, such as 000111010100011100... The first device can randomly select m binary numerical values ​​from the n binary numerical values ​​and form the first target character sequence from the randomly selected m binary numerical values.

[0096] For example, the first device can uniformly and randomly select a message m from a set of bit strings of length n, {0, 1}^n, where message m is the first target character sequence, i.e.: m ← {0, 1} n .

[0097] Regarding the identity identifier of the second device, the first device can receive the identity identifier sent by the second device. For example, the second message can carry the identity identifier, and the first device can parse the identity identifier from the second message.

[0098] For example, this identity identifier represents the user's identity identifier, which is a unique identifier for the user corresponding to the second device (such as a user who uses / logs into the second device), such as an email address, ID card number, or mobile phone number.

[0099] Regarding the device fingerprint of the second device, the first device can obtain the device fingerprint of the second device. This device fingerprint represents the unique device identifier of the second device, such as IMEI, MAC address, device serial number, etc.

[0100] For example, the second device provides a GetDeviceFingerprint interface (device fingerprint acquisition interface). By calling the GetDeviceFingerprint interface, the first device can obtain the device fingerprint of the second device.

[0101] Regarding the random number generated by the second device, the first device can obtain the random number generated by the second device. For example, the second device may include a hardware true random number generator (TRNG), which generates a one-time random number (salt). This one-time random number is used only once, and each call generates a different one-time random number to prevent replay attacks.

[0102] For example, the second device can provide a GetRandom interface (random number retrieval interface). By calling this GetRandom interface, the first device can obtain a random number from the second device.

[0103] In summary, the first device can obtain the first target character sequence, the identity identifier of the second device (denoted as ID), the device fingerprint of the second device (denoted as df), and the random number of the second device (denoted as salt). The device fingerprint can be a 16-byte identifier, and the random number can be a 16-byte random number.

[0104] Step 205: The first device generates a first identity binding confirmation code based on the first target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and the random number of the second device.

[0105] For example, the first device can combine the first target character sequence, the identity identifier, the device fingerprint, and the random number to obtain context information. For instance, the first target character sequence, the identity identifier, the device fingerprint, and the random number can all be numerical values ​​(if not numerical, they are first converted to numerical form). In this way, the first target character sequence, the identity identifier, the device fingerprint, and the random number can be directly concatenated together to obtain the context information. Alternatively, an algorithm (such as addition, subtraction, multiplication, division, XOR, etc.) can be used to perform operations on the first target character sequence, the identity identifier, the device fingerprint, and the random number, and the result can be used as context information; there are no restrictions on this approach.

[0106] For example, it can be represented as: context_msg ← confirm|| ID || df || salt. context_msg represents context information, confirm represents the first target character sequence, ID represents the identity identifier, df represents the device fingerprint, and salt represents a random number. In this way, the context information is obtained by combining the first target character sequence, the identity identifier, the device fingerprint, and the random number. The identity identifier is used to implement identity binding, the device fingerprint is used to implement device binding (hardware binding), and the random number is used to implement non-linkability.

[0107] For example, the first device can perform a quantum-resistant hash operation on the context information to obtain an intermediate value confirmation code of a specified length. For instance, the context information can be input into a quantum-resistant hash algorithm, which processes the context information to obtain an intermediate value confirmation code of the specified length.

[0108] For example, a quantum-resistant hash algorithm can use the SHA3-256 algorithm (which is resistant to quantum collisions). In this case, it can be represented as follows: cd_raw ← SHA3-256(context_msg). That is, the context information context_msg is input into the SHA3-256 algorithm, which processes the context information context_msg and outputs a 32-byte intermediate value confirmation code cd_raw.

[0109] For example, the first device uses the first target character sequence as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the first identity binding confirmation code. Alternatively, the first target character sequence and the intermediate value confirmation code can be input into a cryptographic hash algorithm, which uses the first target character sequence as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the first identity binding confirmation code.

[0110] For example, the cryptographic hash algorithm can be an HMAC (Hash-based Message Authentication Code) algorithm, such as HMAC-SHA3_256. The definition of an HMAC algorithm uses a cryptographic hash function H and a key K. Thus, the first target character sequence can be used as the key K for the HMAC algorithm. The HMAC algorithm performs a cryptographic hash operation on the intermediate confirmation code cd_raw using the key K to obtain the first identity binding confirmation code. For example, it can be represented as: cd ← HMAC-SHA3_256 (key=m, msg=cd_raw), where m represents the first target character sequence, i.e., the session seed m, and cd represents the first identity binding confirmation code.

[0111] In summary, the first device can obtain a first identity binding confirmation code. This first identity binding confirmation code is a type of confirmation data (CD), derived from the message content, used to further verify the correctness of the decryption process during decapsulation. In this embodiment, since the confirmation code is bound to the identity information of the recipient (i.e., the second device), it is called an identity-bound confirmation code (IB-CD), and the identity-bound confirmation code generated by the first device is denoted as the first identity binding confirmation code. The first identity binding confirmation code is a confirmation code generated during the encapsulation stage based on the message content and the recipient's identity ID. It is recalculated during the decapsulation stage and compared with the original confirmation code to ensure that the decapsulation request is initiated by a legitimate user, preventing impersonation attacks and achieving resistance to skipped verification.

[0112] An impersonation attack refers to an attacker posing as a legitimate user in an attempt to obtain system resources or keys. By introducing an identity-bound verification code mechanism, unauthorized identities can be identified without decrypting the key, effectively preventing impersonation attacks. Anti-skipping verification is a security mechanism that ensures critical verification steps in a cryptographic protocol cannot be bypassed. Even if logical errors exist in the code implementation, they can be detected through the identity-bound verification code, i.e., whether the critical verification steps have been executed, thereby preventing unauthorized operations through a multi-layered verification mechanism.

[0113] In one possible implementation, the first device can generate a first identity binding verification code based on a first target character sequence and the identity identifier of the second device. For example, the first device combines the first target character sequence and the identity identifier of the second device to obtain context information, and performs a quantum-resistant hash operation on the context information to obtain an intermediate value verification code of a specified length. Using the first target character sequence as a key, a cryptographic hash operation is performed on the intermediate value verification code to obtain the first identity binding verification code.

[0114] Step 206: The first device performs an encryption operation on the first target character sequence based on the public key of the second device to obtain the first ciphertext parameter. For example, the first device can perform a key derivation operation on the first target character sequence to obtain the random number required for encryption, and the first device can use the public key of the second device to encrypt the first target character sequence and the random number to obtain the first ciphertext parameter.

[0115] For example, a KDF (Key Derivation Function) is a cryptographic function used to securely generate one or more new keys from an initial key, that is, to derive one or more new keys based on a key. Based on this, a first device can perform a KDF-based key derivation operation on a first target character sequence to obtain the random number required for encryption. For instance, the first target character sequence can be used as the initial key, and the random number required for encryption can be used as the derived new key.

[0116] Besides KDF-based key derivation operations, other derivation algorithms can also be used, as long as they can derive the random number required for encryption based on the first target character sequence, such as r = H(m). There are no restrictions on this. m represents the first target character sequence, H represents the derivation algorithm, and r represents the random number required for encryption.

[0117] A public-key encryption algorithm is an algorithm that uses a public key to encrypt data (and a private key paired with the public key to decrypt the data). Based on this, a first device uses the public key of a second device to encrypt a first target character sequence and a random number to obtain a first ciphertext parameter. For example, it can be represented as: Enc(pk, m, r) → c. Enc represents the public-key encryption algorithm, pk represents the public key of the second device, m represents the first target character sequence, r represents the random number required for encryption, and c represents the first ciphertext parameter. In summary, by inputting the first target character sequence m and the random number r into the public-key encryption algorithm, the public-key encryption algorithm can use the public key pk of the second device to perform an encryption operation to obtain the first ciphertext parameter c.

[0118] The processing steps 204-206 are the key encapsulation process.

[0119] Step 207: The first device sends a first message to the second device, and the second device receives the first message. The first message may include a first identity binding confirmation code and a first encrypted parameter.

[0120] For example, the process by which the first device generates a first identity binding verification code based on a first target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and a random number of the second device can be executed in a trusted execution environment. The process by which the first device encrypts the first target character sequence using the public key of the second device to obtain the first ciphertext parameter can also be executed in the trusted execution environment of the first device.

[0121] For example, when the first device sends a first message to the second device, the second device can map the first ciphertext parameter to a confused ciphertext parameter that is indistinguishable from a random string, and the first message includes the confused ciphertext parameter. For instance, the first ciphertext parameter is lattice-based ciphertext, and the confused ciphertext parameter is a random string, such as a uniformly random string of bytes. After receiving the first ciphertext parameter, the first device does not send it to the second device, but instead sends the confused ciphertext parameter. Clearly, the confused ciphertext parameter is a seemingly random string, making the entire handshake traffic statistically difficult to distinguish from random noise or standard TLS traffic, effectively obfuscating the traffic and preventing the leakage of the first ciphertext parameter.

[0122] After receiving the first message, the second device parses the obfuscated ciphertext parameters from the first message based on the position information of the obfuscated ciphertext parameters in the first message, and maps the obfuscated ciphertext parameters to the first ciphertext parameters.

[0123] For example, the second device knows the location information of the obfuscated ciphertext parameter in the first message (the attacker cannot know this location information). If this location information indicates how many consecutive bytes from a certain byte are obfuscated ciphertext parameters, then the obfuscated ciphertext parameter can be parsed from the first message.

[0124] After obtaining the obfuscated ciphertext parameter (i.e., a random string), the second device can map the obfuscated ciphertext parameter to a first ciphertext parameter based on lattice ciphers (such as ML-KEM / Kyber).

[0125] Step 208: After the second device obtains the first ciphertext parameter from the first message, it decrypts the first ciphertext parameter based on the private key of the second device to obtain the second target character sequence.

[0126] A public-key decryption algorithm (corresponding to the public-key encryption algorithm described above) is an algorithm that uses a private key to decrypt data. A second device can use its private key to decrypt the first ciphertext parameter to obtain the second target character sequence. For example, it can be represented as: Dec(sk, c) → m'. Dec represents the public-key decryption algorithm, sk represents the second device's private key, c represents the first ciphertext parameter, and m' represents the second target character sequence. In summary, by inputting the first ciphertext parameter c into the public-key decryption algorithm, the algorithm uses the second device's private key sk to perform the decryption operation, obtaining the second target character sequence m'.

[0127] Since the first ciphertext parameter c is obtained by the first device encrypting the first target character sequence m using the public key of the second device, and the second target character sequence m' is obtained by the second device decrypting the first ciphertext parameter c using the private key of the second device, the second target character sequence m' and the first target character sequence m should be the same. If the second target character sequence m' and the first target character sequence m are different, it means that the second device does not possess the correct private key, that is, the second device is not the correct recipient of the first ciphertext parameter c.

[0128] Step 209: The second device performs an encryption operation on the second target character sequence based on its public key to obtain the second ciphertext parameter. For example, the second device can perform a key derivation operation on the second target character sequence to obtain the random number required for encryption (since the same algorithm is used for key derivation, if the second target character sequence is the same as the first target character sequence, the random number required for encryption obtained by the second device is the same as the random number required for encryption obtained by the first device). The second device can then use its public key to encrypt the second target character sequence and the random number to obtain the second ciphertext parameter. For example, the process in step 209 is similar to that in step 206, and will not be repeated here.

[0129] It is important to note that if the second device is the correct receiver of the first ciphertext parameter c, then the second target character sequence m' is the same as the first target character sequence m, and therefore, the second ciphertext parameter ' is the same as the first ciphertext parameter c. Conversely, if the second device is not the correct receiver of the first ciphertext parameter c, then the second target character sequence m' is different from the first target character sequence m, and the second ciphertext parameter ' is different from the first ciphertext parameter c.

[0130] Step 210: The second device determines whether the second ciphertext parameter is different from the first ciphertext parameter.

[0131] If so, that is, the second ciphertext parameter is different from the first ciphertext parameter, then proceed to step 211;

[0132] If not, that is, if the second ciphertext parameter is the same as the first ciphertext parameter, then proceed to step 212.

[0133] Step 211: The second device determines that the key encapsulation verification of the second device has failed, that is, the identity authentication has failed.

[0134] For example, the FO transformation enhances security by introducing a "de-randomization" mechanism and a "re-encryption check" step. The re-encryption check refers to the following steps: the first device sends a first ciphertext parameter to the second device, the second device calculates a second ciphertext parameter, and determines whether the second ciphertext parameter is different from the first ciphertext parameter. If they are different, it indicates that the key encapsulation verification has failed, that is, the re-encryption check has failed, indicating that the authentication has failed.

[0135] In summary, authentication can be achieved by comparing the second ciphertext parameter with the first ciphertext parameter. If the re-encryption check fails, no data will be transmitted, thus improving the security level.

[0136] In certain scenarios, due to code logic errors, improper exception handling, or human negligence, the "re-encryption check" step may be bypassed or skipped. This means the operation of comparing the second ciphertext parameter with the first ciphertext parameter is not performed, and the second ciphertext parameter is not calculated. Therefore, to determine if the "re-encryption check" step has been bypassed or skipped, if the second ciphertext parameter is the same as the first ciphertext parameter, the identity binding verification code confirmation process can be executed. Since the identity binding verification code confirmation process is executed when the ciphertext parameters are the same, if the identity binding verification code confirmation process is executed, it indicates that the "re-encryption check" step has been executed and has not been bypassed or skipped. Conversely, if the identity binding verification code confirmation process is not executed, it indicates that the "re-encryption check" step has been bypassed or skipped.

[0137] For example, if the "re-encryption check" is performed, it needs to determine whether the second ciphertext parameter is different from the first ciphertext parameter. If they are different, the key encapsulation verification fails, indicating that the re-encryption check has been performed and the result indicates that authentication has failed. If not, the confirmation process using the identity binding verification code is executed. Based on this process, it is known that the re-encryption check has been performed and the result indicates either successful or failed authentication.

[0138] Furthermore, if the "re-encryption check" is not performed, that is, if the second ciphertext parameter is not compared with the first ciphertext parameter, then the confirmation process of executing the identity binding verification code will not be triggered. Therefore, if the confirmation process of executing the identity binding verification code is not triggered, it is determined that the re-encryption check has not been performed.

[0139] Step 212: The second device generates a second identity binding confirmation code based on the second target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and the random number of the second device.

[0140] For example, the second device can combine the second target character sequence, the identity identifier, the device fingerprint, and the random number to obtain context information. The second device can perform a quantum-resistant hash operation on the context information to obtain an intermediate value confirmation code of a specified length. For instance, the context information can be input into a quantum-resistant hash algorithm, which processes the context information to obtain an intermediate value confirmation code of a specified length. The second device uses the second target character sequence as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain a second identity binding confirmation code. For instance, the second target character sequence and the intermediate value confirmation code can be input into a cryptographic hash algorithm, which uses the second target character sequence as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain a second identity binding confirmation code.

[0141] For the second target character sequence, the second device uses its private key to decrypt the first ciphertext parameter to obtain the second target character sequence. Clearly, if the second device is the correct receiver, the second target character sequence will be the same as the first target character sequence. Furthermore, since the second device's identity identifier, device fingerprint, and random number all correspond to the second device, if the second device is the correct receiver, the second identity binding verification code will be the same as the first identity binding verification code. Conversely, if the second identity binding verification code differs from the first identity binding verification code, then the second device is not the correct receiver.

[0142] Step 213: The second device determines whether the second identity binding verification code is different from the first identity binding verification code. If yes, that is, the second identity binding verification code is different from the first identity binding verification code, then proceed to step 214; if no, that is, the second identity binding verification code is the same as the first identity binding verification code, then proceed to step 215.

[0143] Step 214: The second device determines that the key encapsulation verification failed, that is, the identity authentication failed.

[0144] Step 215: The second device confirms that the key encapsulation verification is successful, that is, the identity authentication is successful.

[0145] The processing steps 208-215 are key decapsulation processes.

[0146] The process by which the second device decrypts the first ciphertext parameter using its private key to obtain the second target character sequence can be executed within the trusted execution environment of the second device. The process by which the second device encrypts the second target character sequence using its public key to obtain the second ciphertext parameter can also be executed within the trusted execution environment of the second device. The process by which the second device determines whether the second ciphertext parameter is different from the first ciphertext parameter can also be executed within the trusted execution environment of the second device. The process by which the second device generates a second identity binding verification code based on the second target character sequence, the second device's identity identifier, the device fingerprint, and a random number can also be executed within the trusted execution environment of the second device. The process by which the second device determines whether the second identity binding verification code is different from the first identity binding verification code can also be executed within the trusted execution environment of the second device.

[0147] In one possible implementation, after the second device confirms successful key encapsulation verification, it can further perform a key derivation operation on the second target character sequence to obtain a target shared key. Additionally, the first device performs a key derivation operation on the first target character sequence to obtain the target shared key. Since the second target character sequence and the first target character sequence are identical, the target shared key obtained by the second device is the same as the target shared key obtained by the first device, thus enabling encryption and decryption to be performed using the same target shared key.

[0148] For example, the second device can perform a KDF-based key derivation operation on the second target character sequence to obtain the target shared key, or it can use other key derivation algorithms to perform key derivation operations on the second target character sequence to obtain the target shared key. Similarly, the first device can perform a KDF-based key derivation operation on the first target character sequence to obtain the target shared key, or it can use other key derivation algorithms to perform key derivation operations on the first target character sequence to obtain the target shared key.

[0149] For example, it can be represented by the following expression: K=G(m), where m represents the second target character sequence or the first target character sequence, G represents the key derivation algorithm, and K represents the target shared key.

[0150] The second device can encrypt or decrypt application data exchanged between the first and second devices based on the target shared key. For example, the second device can use the AEAD algorithm for encryption or decryption based on the target shared key. The first device can also encrypt or decrypt application data exchanged between the first and second devices based on the target shared key. For example, the first device can use the AEAD algorithm for encryption or decryption based on the target shared key.

[0151] For application data sent from the first device to the second device, the first device encrypts the application data based on the target shared key, and the second device decrypts the application data based on the target shared key.

[0152] For application data sent from the second device to the first device, the second device encrypts the application data based on the target shared key, and the first device decrypts the application data based on the target shared key.

[0153] As can be seen from the above technical solutions, the embodiments of this application propose a key encapsulation mechanism based on a Trusted Execution Environment (TEE) with identity binding and obfuscation capabilities. This mechanism achieves security protections against quantum computing, software implementation vulnerabilities, identity impersonation, and network censorship, providing a solution for communication systems in high-security scenarios. For example, in communication scenarios such as anti-network censorship communication systems, mobile payments, and remote key encapsulation verification, it can effectively resist Adaptive Choice Ciphertext Attacks (IND-CCA), software implementation vulnerabilities, identity impersonation attacks, and network traffic analysis censorship.

[0154] Implementing a hardware-level secure execution mechanism based on TEE: This involves migrating critical and vulnerable decapsulation and verification logic (including private key management, re-encryption checks, and identity binding verification) from the key encapsulation mechanism to the TEE for execution, thus addressing security vulnerabilities. For example, the recipient's (second device's) long-term private key never leaves the TEE, preventing key leakage risks. Key security steps such as re-encryption checks and identity binding verification are completed in isolated memory within the TEE, utilizing hardware-level integrity protection to prevent control flow tampering. Even if an attacker gains complete control of the operating system (REE), they cannot bypass or disable the security verification logic within the TEE. This enables a shift from "software-trusted" to "hardware-trusted," effectively resisting security degradation caused by code implementation errors, exception handling defects, or malware, significantly improving system robustness and reliability.

[0155] The sender performs key encapsulation within the REE, while the receiver's REE receives the ciphertext and transmits it to the TEE for secure processing. The receiver performs key decapsulation, re-encryption checks, and identity binding verification within the isolated environment of the REE, preventing security degradation due to software implementation vulnerabilities. Combined with the TEE's remote authentication function, this enables both communicating parties to verify each other's execution environments. Both the sender and receiver run key encapsulation within the TEE, forming an end-to-end hardware trust chain, ensuring the entire key exchange process is completed in a trusted, secure, and anonymous environment. The receiver's private key (sk), identity identifier (ID), and decapsulation algorithm are securely deployed within the TEE, running as a Trusted Application (TA). The REE handles ordinary network communication and transmits received ciphertext to the TA within the TEE for processing via secure channels (such as the GlobalPlatform TEE Client API). The TEE, through a remote authentication mechanism, can prove the authenticity and integrity of its operating environment to the sender.

[0156] An enhanced identity-binding verification mechanism is implemented: In addition to the re-encryption check of the FO transformation, an identity-binding verification code is introduced as a second verification mechanism (i.e., based on the message and the receiver's identity identifier). This binds the identity information of both communicating parties to the key exchange process, achieving implicit two-way key encapsulation verification. During the encapsulation phase, the sender generates a verification code (cd) strongly associated with the receiver's identity ID. When decapsulating, the receiver needs to recalculate cd' using the locally stored identity ID and compare it with the received cd. If the identities do not match or the ciphertext is tampered with, the verification fails, and the shared key is rejected. This implicit two-way key encapsulation verification effectively defends against impersonation and replay attacks. Even if an attacker intercepts legitimate ciphertext, they cannot use it for communication with other identities. Without significantly increasing communication overhead, the protocol's authentication and anti-abuse capabilities are enhanced, compensating for the lack of identity binding in KEM.

[0157] This ensures that even the same message 'm' generates different acknowledgment codes under different identity IDs, thus preventing attackers from using the same ciphertext to impersonate multiple identities. By introducing identity information into the acknowledgment code generation process, implicit key encapsulation verification is achieved. This allows for identification of the source of illegal requests without decapsulating the key, significantly enhancing the system's resistance to impersonation attacks. It effectively prevents attackers from forging or tampering with ciphertext for illegal decapsulation, improving the protocol's resistance to chosen-ciphertext attacks. The strong binding of the acknowledgment code to the identity enhances the system's key encapsulation verification strength, preventing impersonation attacks. Even if there are implementation logic errors, anomalies can be captured through acknowledgment code verification, avoiding security degradation.

[0158] Building upon the FO transformation, a two-step verification mechanism is introduced to form a multi-layered security protection system. These two steps are re-encryption checking and acknowledgment code consistency comparison. For re-encryption checking, during decapsulation, the receiver uses the decrypted message to re-derive randomness and performs encryption to generate new ciphertext. The newly generated ciphertext is compared with the original ciphertext to verify message integrity and the correctness of the decryption process. For acknowledgment code consistency comparison, the receiver recalculates the acknowledgment code based on the decrypted message and its own identity information and compares it with the original acknowledgment code. If they do not match, the decapsulation request is deemed invalid, and the shared key is refused. These two verification steps together constitute a "double insurance" mechanism, effectively preventing the security verification process from being skipped or bypassed due to control flow errors, logical vulnerabilities, or malicious tampering, thereby improving the security and robustness of the entire key encapsulation mechanism in actual deployment.

[0159] The identity binding verification code mechanism in this embodiment has good versatility and adaptability, and is applicable to all post-quantum secure key encapsulation mechanisms (KEM) that support FO transformation, including but not limited to Kyber, HQC, FrodoKEM, NTRU Prime, etc. It can be seamlessly integrated into the post-quantum cryptography protocol stack without changing the encryption scheme structure, maintaining low performance overhead and possessing good scalability, making it suitable for high-security scenarios such as TLS / DTLS protocols, IoT device authentication, and zero-knowledge authentication.

[0160] A post-quantum-secure traffic obfuscation mechanism: By employing an obfuscated key encapsulation mechanism, the public key and ciphertext are converted into a form indistinguishable from random strings, achieving proactive concealment of communication traffic. The transmitted obfuscated key and obfuscated ciphertext are highly similar to random noise or TLC traffic in byte distribution, packet length, and timing characteristics, thus providing post-quantum security and resisting quantum computing threats. Achieving probe resistance effectively circumvents network censorship based on deep packet inspection (DPI) or traffic fingerprinting. Combining cryptographic security with network-layer anonymity achieves probe resistance against network censorship.

[0161] In this embodiment, a secure communication framework combining hardware root of trust, key encapsulation verification, and traffic obfuscation is constructed. This framework deeply integrates the hardware security capabilities of the TEE, the logical authentication mechanism of identity binding, and transport layer obfuscation technology to form an end-to-end collaborative security system, providing a solution for high-security scenarios. Hardware root of trust, key encapsulation verification, and traffic obfuscation form an organically collaborative security system. The TEE provides a trusted root for the execution environment, ensuring the unbypassability of identity binding and re-encryption checks. The identity binding confirmation code provides logical layer authentication guarantees, enhancing the protocol's inherent resistance to impersonation and replay attacks. Obfuscation encoding provides transport layer stealth capabilities, making communication physically difficult to identify and block. The combination of these three elements constructs a comprehensive secure communication framework that is end-to-end trusted, quantum-resistant, vulnerability-resistant, identity-impersonation-resistant, and censorship-resistant.

[0162] Based on the same application concept as the above method, this application proposes an anti-skip verification key encapsulation device based on an identity binding confirmation code, applied to a first device in a system. The system also includes a second device, see [link to relevant documentation]. Figure 3A The diagram shown is a structural schematic of the device, which may include:

[0163] The generation module 311 is used to generate a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device; wherein, the first target character sequence is obtained by the first device selecting characters from the generated string set, and the identity identifier represents the user's identity identifier;

[0164] Processing module 312 is used to perform an encryption operation on the first target character sequence based on the obtained public key of the second device to obtain the first ciphertext parameter corresponding to the first target character sequence; wherein, the public key of the second device is generated by the second device in a trusted execution environment;

[0165] The sending module 313 is used to send a first message to the second device, the first message including the first identity binding confirmation code and the first ciphertext parameter; so that the second device determines whether the key encapsulation verification failed or succeeded based on the first identity binding confirmation code and the first ciphertext parameter.

[0166] For example, when the generation module 311 generates the first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device, it is specifically used to: generate the first identity binding confirmation code based on the first target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and the random number of the second device; wherein, the first target character sequence can be obtained by the first device selecting characters from the generated string set, the identity identifier can represent the user's identity identifier, the device fingerprint can represent the unique device identifier of the second device, and the random number can be randomly generated by the second device; wherein, the first target character sequence, the identity identifier, the device fingerprint, and the random number are combined to obtain context information; a quantum-resistant hash operation is performed on the context information to obtain an intermediate value confirmation code of a specified length; the first target character sequence is used as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the first identity binding confirmation code.

[0167] For example, when the processing module 312 performs an encryption operation on the first target character sequence based on the public key of the second device to obtain the first ciphertext parameter corresponding to the first target character sequence, it is specifically used to: perform a key derivation operation on the first target character sequence to obtain a random number required for encryption, and use the public key of the second device to perform an encryption operation on the first target character sequence and the random number to obtain the first ciphertext parameter.

[0168] Based on the same application concept as the above method, this application proposes an anti-skip verification key encapsulation device based on an identity binding confirmation code, applied to a second device in a system. The system also includes a first device. See [link to relevant documentation]. Figure 3B The diagram shown is a structural schematic of the device, which may include:

[0169] The receiving module 321 is used to receive a first message sent by the first device. The first message includes a first identity binding confirmation code and a first ciphertext parameter. The first identity binding confirmation code is generated by the first device based on a first target character sequence and the identity identifier of the second device. The first ciphertext parameter is obtained by the first device encrypting the first target character sequence based on the public key of the second device.

[0170] Processing module 322 is used to decrypt the first ciphertext parameter based on the private key of the second device to obtain a second target character sequence; and to encrypt the second target character sequence based on the public key of the second device to obtain a second ciphertext parameter.

[0171] The determining module 323 is configured to: if the second ciphertext parameter is different from the first ciphertext parameter, determine that the key encapsulation verification of the second device has failed; if the second ciphertext parameter is the same as the first ciphertext parameter, generate a second identity binding confirmation code based on the second target character sequence and the identity identifier of the second device; if the second identity binding confirmation code is different from the first identity binding confirmation code, determine that the key encapsulation verification of the second device has failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, determine that the key encapsulation verification of the second device has succeeded.

[0172] For example, when the determining module 323 generates the second identity binding confirmation code based on the second target character sequence and the identity identifier of the second device, it is specifically used to: generate the second identity binding confirmation code based on the second target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and the random number of the second device; wherein, the second target character sequence can be obtained by the second device selecting characters from the generated string set, the identity identifier can represent the user's identity identifier, the device fingerprint can represent the unique device identifier of the second device, and the random number can be randomly generated by the second device; wherein, the second target character sequence, the identity identifier, the device fingerprint, and the random number are combined to obtain context information; a quantum-resistant hash operation is performed on the context information to obtain an intermediate value confirmation code of a specified length; the second target character sequence is used as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the second identity binding confirmation code.

[0173] For example, the processing module 322 is further configured to generate a private key of the second device and a public key paired with the private key, and map the public key to a confused public key, wherein the public key is a lattice-based public key and the confused public key is a random string; and the processing module 322 is further configured to send a second message to the first device; wherein the second message may include an invalid random string and a confused public key indistinguishable from the invalid random string; wherein, based on the position information of the confused public key in the second message, the first device parses the confused public key from the second message and maps the confused public key to the public key of the second device.

[0174] For example, the second device includes a trusted execution environment and a rich execution environment. The trusted execution environment is a secure execution area that is isolated from the operating system and protected by hardware. The rich execution environment is an open environment that runs the operating system. The trusted execution environment is isolated from the rich execution environment. When generating a private key and a public key that is paired with the private key, the private key and the public key are generated in the trusted execution environment, and the private key is prohibited from leaving the trusted execution environment.

[0175] For example, when the processing module 322 performs an encryption operation on the second target character sequence based on the public key of the second device to obtain the second ciphertext parameter, it is specifically used to: the second device performs a key derivation operation on the second target character sequence to obtain a random number required for encryption, and uses the public key of the second device to perform an encryption operation on the second target character sequence and the random number to obtain the second ciphertext parameter.

[0176] Based on the same application concept as the above method, this application proposes an electronic device (such as the first device or the second device in the above examples), see [link]. Figure 4 As shown, the electronic device includes a processor 41 and a machine-readable storage medium 42, wherein the machine-readable storage medium 42 stores machine-executable instructions that can be executed by the processor 41; the processor 41 is used to execute the machine-executable instructions to implement the anti-skip verification key encapsulation method based on identity binding confirmation code disclosed in the above example of this application.

[0177] Based on the same application concept as the above method, this application embodiment also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, implement the above example of an anti-skip verification key encapsulation method based on identity binding confirmation code.

[0178] The aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0179] Based on the same application concept as the above method, this application embodiment also provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the anti-skip verification key encapsulation method based on identity binding confirmation code disclosed in the above example of this application.

[0180] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0181] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for encapsulating a key that resists skipped verification based on an identity binding confirmation code, characterized in that, Applied to a system including a first device and a second device, the method includes: The first device generates a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device; it encrypts the first target character sequence based on the acquired public key of the second device to obtain a first ciphertext parameter; and it sends a first message to the second device, the first message including the first identity binding confirmation code and the first ciphertext parameter. The second device decrypts the first ciphertext parameter using its private key to obtain a second target character sequence; it then encrypts the second target character sequence using its public key to obtain a second ciphertext parameter; if the second ciphertext parameter is different from the first ciphertext parameter, the key encapsulation verification of the second device is determined to have failed. If the second ciphertext parameter is the same as the first ciphertext parameter, the second device generates a second identity binding confirmation code based on the second target character sequence and the identity identifier of the second device; If the second identity binding confirmation code is different from the first identity binding confirmation code, the second device determines that the key encapsulation verification has failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the second device determines that the key encapsulation verification has succeeded.

2. The method according to claim 1, characterized in that, The first device generates a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device, including: The first device generates a first identity binding confirmation code based on the first target character sequence, the identity identifier of the second device, the device fingerprint of the second device, and the random number of the second device; Wherein, the first target character sequence is obtained by the first device selecting characters from the generated string set, the identity identifier represents the user's identity identifier, the device fingerprint represents the unique device identifier of the second device, and the random number is randomly generated by the second device; Specifically, the first target character sequence, the identity identifier, the device fingerprint, and the random number are combined to obtain context information; a quantum-resistant hash operation is performed on the context information to obtain an intermediate value confirmation code of a specified length; the first target character sequence is used as a key to perform a cryptographic hash operation on the intermediate value confirmation code to obtain the first identity binding confirmation code.

3. The method according to claim 1, characterized in that, Before the first device performs an encryption operation on the first target character sequence based on the obtained public key of the second device to obtain the first ciphertext parameter, the method further includes: The second device generates a private key and a public key paired with the private key, and maps the public key to a confused public key. The public key is a lattice-based public key, and the confused public key is a random string. The second device sends a second message to the first device; wherein the second message includes an invalid random string and the obfuscated public key that is indistinguishable from the invalid random string; Based on the location information of the obfuscated public key in the second message, the first device parses the obfuscated public key from the second message and maps the obfuscated public key to the public key of the second device.

4. The method according to claim 3, characterized in that, The second device includes a trusted execution environment and a rich execution environment. The trusted execution environment is a secure execution area isolated from the operating system and protected by hardware. The rich execution environment is an open environment running the operating system. The trusted execution environment is isolated from the rich execution environment. Specifically, when the second device generates the private key and the public key that are paired with the private key, it generates the private key and the public key in the trusted execution environment, and prohibits the private key from leaving the trusted execution environment.

5. The method according to claim 1, characterized in that, The first device performs an encryption operation on the first target character sequence based on the public key of the second device to obtain a first ciphertext parameter, including: performing a key derivation operation on the first target character sequence to obtain a random number required for encryption, and using the public key of the second device to encrypt the first target character sequence and the random number to obtain the first ciphertext parameter; The second device performs an encryption operation on the second target character sequence based on the public key of the second device to obtain a second ciphertext parameter, including: the second device performs a key derivation operation on the second target character sequence to obtain a random number required for encryption, and uses the public key of the second device to encrypt the second target character sequence and the random number to obtain the second ciphertext parameter.

6. The method according to claim 1, characterized in that, After the second device determines that the key encapsulation verification is successful, the method further includes: The second device performs a key derivation operation on the second target character sequence to obtain a target shared key; wherein, the second device performs encryption or decryption operations on the application data exchanged between the first device and the second device based on the target shared key; The first device performs a key derivation operation on the first target character sequence to obtain a target shared key; wherein, the first device performs encryption or decryption operations on application data exchanged between the first device and the second device based on the target shared key.

7. A method for encapsulating a key that resists skipped verification based on an identity binding confirmation code, characterized in that, The method comprises: a first device applied in a system, the system further comprising a second device, and the method comprising: A first identity binding confirmation code is generated based on the acquired first target character sequence and the identity identifier of the second device; wherein, the first target character sequence is obtained by the first device selecting characters from a pre-generated string set, and the identity identifier represents the user's identity identifier; The first target character sequence is encrypted using the obtained public key of the second device to obtain the first ciphertext parameter; wherein the public key is generated by the second device in a trusted execution environment; Send a first message to the second device, the first message including the first identity binding confirmation code and the first ciphertext parameter; so that the second device determines whether the key encapsulation verification of the second device has failed or succeeded based on the first identity binding confirmation code and the first ciphertext parameter.

8. A method for encapsulating a key that resists skipped verification based on an identity binding confirmation code, characterized in that, The method includes a second device applied to the system, the system further including the first device, and the method comprising: The system receives a first message sent by a first device, the first message including a first identity binding confirmation code and a first ciphertext parameter; wherein, the first identity binding confirmation code is generated by the first device based on the acquired first target character sequence and the identity identifier of the second device, and the first ciphertext parameter is obtained by the first device encrypting the first target character sequence based on the public key of the second device; The first ciphertext parameter is decrypted using the private key of the second device to obtain the second target character sequence; the second target character sequence is encrypted using the public key of the second device to obtain the second ciphertext parameter; if the second ciphertext parameter is different from the first ciphertext parameter, the key encapsulation verification of the second device is determined to have failed; if the second ciphertext parameter is the same as the first ciphertext parameter, a second identity binding confirmation code is generated based on the second target character sequence and the identity identifier of the second device. If the second identity binding confirmation code is different from the first identity binding confirmation code, the key encapsulation verification of the second device is determined to have failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, the key encapsulation verification of the second device is determined to have succeeded.

9. A key encapsulation device for preventing skipped verification based on identity binding confirmation code, characterized in that, A first device applied in the system, the system further including a second device, the device comprising: The generation module is used to generate a first identity binding confirmation code based on the acquired first target character sequence and the identity identifier of the second device; wherein, the first target character sequence is obtained by the first device selecting characters from the generated string set, and the identity identifier represents the user's identity identifier; The processing module is used to perform an encryption operation on the first target character sequence based on the obtained public key of the second device to obtain the first ciphertext parameter corresponding to the first target character sequence; wherein, the public key of the second device is generated by the second device in a trusted execution environment; The sending module is configured to send a first message to the second device, the first message including the first identity binding confirmation code and the first ciphertext parameter; so that the second device determines whether the key encapsulation verification failed or succeeded based on the first identity binding confirmation code and the first ciphertext parameter.

10. A key encapsulation device for preventing skipped verification based on identity binding confirmation code, characterized in that, A second device is applied to the system, the system further including the first device, the device comprising: The receiving module is used to receive a first message sent by the first device. The first message includes a first identity binding confirmation code and a first ciphertext parameter. The first identity binding confirmation code is generated by the first device based on a first target character sequence and the identity identifier of the second device. The first ciphertext parameter is obtained by the first device encrypting the first target character sequence based on the public key of the second device. The processing module is configured to decrypt the first ciphertext parameter based on the private key of the second device to obtain a second target character sequence; and encrypt the second target character sequence based on the public key of the second device to obtain a second ciphertext parameter. The determination module is configured to: if the second ciphertext parameter is different from the first ciphertext parameter, determine that the key encapsulation verification of the second device has failed; if the second ciphertext parameter is the same as the first ciphertext parameter, generate a second identity binding confirmation code based on the second target character sequence and the identity identifier of the second device; if the second identity binding confirmation code is different from the first identity binding confirmation code, determine that the key encapsulation verification of the second device has failed; if the second identity binding confirmation code is the same as the first identity binding confirmation code, determine that the key encapsulation verification of the second device has succeeded.

Images