Equipment anonymous verification method and system, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a device anonymous verification method and system, an electronic device, a storage medium and a program product. The method is applied to a device end. The method comprises the following steps: acquiring an anonymous equipment identifier, wherein the anonymous equipment identifier is generated based on an unexported root key and equipment hardware characteristics in a hardware security module of an equipment end; sending the anonymous device identifier and a public key corresponding to the anonymous device identifier to a verification end; receiving challenge information from the verification end; signing the challenge information by using the non-export root key to obtain a signature response; and sending the signature response to the verification end, so that the verification end verifies the signature response based on the public key to complete anonymous verification of the device. On the premise that the real identity of the equipment is not exposed completely, strong authentication is completed based on the hardware trusted root.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, system, electronic device, storage medium, and program product for anonymous device verification. Background Technology

[0002] With the widespread application of cloud computing, edge computing and container technologies, data collected by user-end devices (such as terminals, IoT, edge nodes) needs to be uploaded to the cloud or edge server for processing.

[0003] However, in related technologies, device identity information (such as MAC address, device serial number, and certificate) is often directly exposed on the platform. This can lead to problems such as the user's device identity being traceable, lack of anonymity, and the container platform's inability to ensure that data can only be decrypted by designated devices. Summary of the Invention

[0004] The purpose of this application is to provide a device anonymity verification method, system, electronic device, storage medium, and program product to achieve the technical effect of improving the anonymity of device verification.

[0005] A first aspect of this application provides a device anonymity verification method, the method being applied to a device; the method includes: Obtain the anonymous device identifier, which is generated based on the non-derivative root key in the hardware security module of the device and the device hardware characteristics; Send the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification terminal; Receive challenge information from the verification terminal; The challenge information is signed using the non-derivative root key to obtain a signed response; The signature response is sent to the verification terminal, so that the verification terminal verifies the signature response based on the public key to complete the anonymous verification of the device.

[0006] In the above implementation process, strong authentication is completed based on a hardware root of trust without revealing the device's true identity. This resolves the conflict between identity privacy protection and platform trusted verification. The device can prove its legitimacy to the verification platform using only dynamically generated anonymous identifiers and cryptographic credentials.

[0007] Furthermore, the anonymous device identifier is generated based on a one-way function of the non-derivative root key, the device hardware characteristics, and a time factor.

[0008] In the above implementation process, by introducing a time factor and combining it with a one-way function to generate anonymous identifiers, dynamics and timeliness are injected into device identity, so that the same device will generate different identifiers at different sessions or time points, thus breaking the long-term behavior tracking chain.

[0009] Furthermore, before sending the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification terminal, the method further includes: Generate an asymmetric key pair based on the aforementioned underivative root key; The public key portion of the asymmetric key pair is determined as the public key.

[0010] In the above implementation process, by deriving temporary asymmetric key pairs based on the non-derivative root key within the hardware security module for communication, secure isolation and fine-grained management of key usage are achieved. This maintains a strong association with the hardware root of trust while reducing the risk of direct exposure of the root key.

[0011] Furthermore, the challenge information is a one-time random number generated by the verification end.

[0012] In the above implementation process, by limiting the challenge information to a one-time random number generated by the verification end, the uniqueness of each authentication session is ensured, thereby preventing replay attacks.

[0013] Furthermore, the device hardware features include at least one of the following: a central processing unit serial number, a platform configuration register value of a trusted platform module, and endorsement key information of the hardware security module.

[0014] In the above implementation process, multiple reliable and tamper-resistant hardware dimensions for anchoring anonymous identifiers to specific physical devices were clarified, ensuring that the generated anonymous identifiers have strong device uniqueness and providing a feasible basis for one device, one secret.

[0015] Furthermore, the hardware security module is a trusted platform module or a trusted execution environment.

[0016] In the above implementation process, the hardware security module can be based on either TPM or TEE, two standardized hardware security technologies, to cover different device types ranging from stand-alone security chips to integrated security zones.

[0017] A second aspect of this application provides a device anonymity verification system, the system comprising: On the device side, it is used to obtain the anonymous device identifier and send the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification end. The anonymous device identifier is generated based on the non-derivative root key in the hardware security module of the device side and the device hardware characteristics. The verification terminal is used to receive the anonymous device identifier and the public key, and send challenge information to the device terminal; The device is also used to receive the challenge information, sign the challenge information using the non-derivative root key to obtain a signature response, and send the signature response to the verification end. The verification terminal is also used to verify the signature response based on the public key to complete anonymous verification for the device.

[0018] In the above implementation process, anonymous verification based on hardware root of trust was achieved through clear division of labor and interaction on the terminal side.

[0019] Furthermore, the verification terminal is also used to determine the device terminal corresponding to the anonymous device identifier as a legitimate device if it is determined that the signature response based on the public key has been verified as legitimate.

[0020] In the above implementation process, by marking the device as a legitimate device, the state transition from successful verification to authorization is realized. Only legitimate devices can access subsequent resources and services, thereby achieving manageability in an anonymous environment.

[0021] Furthermore, the verification end is also used to, upon determining that the signature response verified based on the public key has passed, derive an encryption resource and container policy based on the anonymous device identifier, and create a target container bound to the anonymous device identifier. The target container is used to process data from the device end corresponding to the anonymous device identifier based on the encryption resources.

[0022] In the above implementation process, after the verification is successful, the verification end dynamically derives resources based on the anonymous identifier and creates a strongly bound container, realizing the delivery from anonymous authentication to dedicated secure computing resources, and constructing a strongly isolated data closed loop of one device, one container, and one key.

[0023] A third aspect of this application provides an electronic device, the electronic device comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements any of the methods described in the first aspect.

[0024] A fourth aspect of this application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first aspect.

[0025] A fifth aspect of this application provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements any of the methods described in the first aspect. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A distributed centralized management device architecture diagram provided for embodiments of this application; Figure 2 A schematic diagram of a container scheduling process for a device management service provided in this application embodiment; Figure 3 A flowchart illustrating a device anonymization verification method provided in this application embodiment; Figure 4 A system architecture diagram provided for an embodiment of this application; Figure 5 This application provides a schematic diagram of device-platform interaction. Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0029] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] Related technologies include distributed centralized device management methods and container scheduling methods based on device management services. Among them, such as... Figure 1 As shown, the distributed centralized management method achieves centralized management of different numbers of devices through distributed elastic technology. However, it has the following drawbacks: 1. Risk of identity exposure: Device identity information (such as certificates and serial numbers) is directly uploaded, allowing the platform to track user devices; 2. It is difficult to complete device authentication and data authorization without revealing one's identity.

[0031] like Figure 2 As shown, for the method of container scheduling based on device management service, the scheduling process of device management service is divided into the following steps: 1. Acquisition unit, used to acquire scheduling data from the device management service; 2. A generation unit, used to generate resource container group information corresponding to the scheduling data based on the scheduling data; 3. Deployment unit, used to deploy the resource container group according to the resource container group information; 4. A running unit for running the device management service using the deployed resource container group.

[0032] While the container scheduling method based on device management services achieves dynamic orchestration of server-side containers, it has the following drawbacks: 1. Strong binding between devices and containers is not implemented: separate storage and computation of device privacy data cannot be supported; 2. Insufficient data isolation: After container migration or snapshot, data can still be decrypted on other devices, which cannot prevent data leakage.

[0033] This application aims to address the following problems existing in the related technologies regarding device authentication and device data uploading to cloud servers: 1. Device identity leakage risk: Traditional device authentication mechanisms often rely on unique device identifiers (such as MAC address, IMEI, etc.), which are easily tracked and forged, leading to user privacy leakage or identity forgery attacks; 2. Insecure device-container binding: In related container deployment solutions, there is a lack of strong binding mechanisms between devices and containers. Containers are easily migrated or copied, leading to data isolation failure, service abuse, or lateral attacks. 3. Key management is complex and insecure: Device keys are often stored in ordinary storage media, which are easy to extract or tamper with. They lack the support of a root of trust and it is difficult to ensure the security of the key's life cycle. 4. The platform cannot verify the authenticity of the device's identity: The platform relies heavily on the device to actively report its identity information, and lacks effective means to verify the authenticity of the device's identity, which poses a risk of fraudulent access.

[0034] To this end, this application integrates TPM / TEE security hardware devices with the platform to build a security mechanism that is identity-free and strongly bound, ensuring device anonymity, identity trustworthiness, and container isolation.

[0035] To address any of the issues raised above, embodiments of this application provide a method for anonymous device verification, referring to... Figure 3 , Figure 3 This is a flowchart illustrating a device anonymization verification method provided in an embodiment of this application.

[0036] In this embodiment, the method is applied to the device side; the method includes: Step S10: Obtain the anonymous device identifier, which is generated based on the non-derivative root key in the hardware security module of the device and the device hardware characteristics; It should be noted that the device side refers to the physical device that needs to be verified, such as IoT terminals, edge computing nodes, mobile phones, servers, etc.

[0037] Hardware security module: A physically or logically isolated environment that provides secure storage and cryptographic capabilities. The hardware security module generates and stores keys to prevent unauthorized reading or copying. Exemplarily, the hardware security module includes a Trusted Platform Module (TPM, a stand-alone security chip) or a Trusted Execution Environment (TEE, a secure area integrated within the CPU).

[0038] Non-exportable root key: A cryptographic key (which can be the private key of an asymmetric key pair) generated and permanently resided within the aforementioned hardware security module. Non-exportable means that the plaintext form of this key cannot be read or transmitted outside the module under any circumstances, and it is the foundation of the device's uniqueness and trustworthiness.

[0039] Device hardware characteristics: Inherent, tamper-proof information that uniquely identifies the hardware of a device. Examples include a CPU's unique serial number, a TPM's endorsement key digest, or a fixed value in a specific register. It is used to bind the root key to this specific device.

[0040] Anonymous device identifier: An identifier obtained by combining a non-derivative root key with device hardware characteristics through cryptographic methods (such as hashing, HMAC).

[0041] It should be understood that the identifier achieves uniqueness due to the uniqueness of the root key and hardware characteristics; the anonymous device identifier itself does not contain plaintext hardware information (such as MAC address), and due to the characteristics of the one-way function, the original root key or hardware characteristics cannot be derived from it, thus protecting the true identity of the device.

[0042] Specifically, the anonymous device identifier is generated by the device itself.

[0043] The anonymous device identifier serves as a "temporary pseudonym" for the device during this authentication session. In other words, the purpose of generating or obtaining the anonymous device identifier is to create a publicly available "digital code" for the device that can be used in this session without revealing its identity.

[0044] Step S20: Send the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification terminal; It should be noted that the public key is the public part that is paired with the non-derivative root key (as the private key). This public key can be the public key of the hardware security module's root key pair, or it can be the public key of another pair of temporary keys derived from the root key.

[0045] Step S30: Receive challenge information from the verification terminal; It's important to note that the challenge information is a random, unpredictable piece of data generated by the verification end. Its purpose is to prevent replay attacks, preventing attackers from impersonating the device by eavesdropping on and repeating old conversations. The verification end generates a new challenge for each verification, ensuring that the device's response is generated specifically for the current session, rather than a copied old response.

[0046] Step S40: Sign the challenge information using the non-derivative root key to obtain a signature response; It should be noted that the signing operation is completed within the hardware security module on the device side.

[0047] A signature is a cryptographic operation that uses a private key to process a piece of data (i.e., the challenge information) and generate a unique signature response. Any entity possessing the corresponding public key can verify whether the signature was indeed generated by that private key and whether the data has been tampered with.

[0048] Signature response: The output of the signature operation is the device's answer to the challenge information.

[0049] It should be understood that the device, within its hardware security module, uses a non-derivative root key (private key) that is inaccessible from the outside to sign the challenge message. This proves that: The device does indeed possess a genuine private key that matches the previously sent public key; This private key is protected at the hardware level (because it can be used to sign). The device responds to the challenge in real time within the current session (because the challenge is new).

[0050] Step S50: Send the signature response to the verification terminal so that the verification terminal verifies the signature response based on the public key to complete the anonymous verification of the device.

[0051] Specifically, the verifier uses the received public key to decrypt and verify the signed response. It checks whether the signature was indeed generated by the challenge message sent using the corresponding private key.

[0052] It should be noted that if the verification passes, it proves that: The device is real (possesses a legitimate private key protected by hardware). The identity is anonymous: throughout the process, the verification end only knows the anonymous device identifier and public key, neither of which can be directly linked to the device's real-world identity (such as owner, location, etc.).

[0053] In this embodiment, the device actively generates an anonymous, hardware-based identifier through a hardware security module and completes a one-time cryptographic challenge using a non-derivative key within the module. The entire process ensures that the device can prove to the verifier that "I am a legitimate and unique hardware device," while completely concealing "who I am (my true identity)." This resolves the contradiction between the risk of identity exposure and the need for trusted authentication in related technologies, laying a secure foundation for subsequent privacy services (such as secure data uploads and dedicated container binding).

[0054] In this embodiment, strong authentication is achieved based on a hardware root of trust without revealing the device's true identity. This resolves the conflict between identity privacy protection and platform-based trusted verification. The device can prove its legitimacy to the verification platform using only dynamically generated anonymous identifiers and cryptographic credentials.

[0055] Based on any of the above embodiments, the anonymous device identifier is generated based on a one-way function of the non-derivative root key, the device hardware characteristics, and a time factor.

[0056] It should be noted that this embodiment achieves dynamic anonymity of device identity rather than static anonymity. It creates a dynamic anonymous device identifier that is time-sensitive, unique, irreversible, and does not expose the true identity.

[0057] Optionally, the anonymous device identifier is generated based on a one-way function representing the non-derivative root key, the device hardware characteristics, and a time factor.

[0058] Representative value of the non-derivative root key: Due to the non-derivative hardware property of the root key itself, its plaintext value cannot be directly used for calculation. Therefore, in practice, its representative value can be used as input. This representative value includes, but is not limited to: Key handle: A logical identifier used internally by the hardware security module to reference the key; Derived values: One or more temporary values ​​generated using the key derivation function (KDF) based on the root key and used only for this calculation.

[0059] The reason for using the non-derivative root key is to ensure that the generated identifier is strongly bound to the device's trusted hardware root.

[0060] Device hardware characteristics: such as the central processing unit serial number, the platform configuration register value of the trusted platform module, etc. This input anchors the generated identifier to this specific physical device, which is the material basis for achieving one-device-one-secret.

[0061] Time factor: A dynamically changing parameter that can be taken from the current timestamp of a trusted clock on the device. The timestamp's precision (e.g., milliseconds) must be sufficient to distinguish between consecutive operations.

[0062] The reason for introducing the time factor is because: Anti-long-term tracking: Even for the same device, due to the constantly changing time factor, the anonymous device identifier generated at different points in time (such as different sessions or different device startup cycles) will be different. This makes it impossible for external observers or platforms to correlate the device's activities at different times, effectively breaking the chain of long-term behavior tracking; Forward anonymity: The old identifier used by a device during a certain period of time becomes invalid after the time factor is updated and cannot be associated with the new identifier, thus realizing forward anonymity update of identity; Regularly force identity refresh to defend against replay attacks: Because the identifier is time-sensitive, if an attacker intercepts an expired identifier and the corresponding session data, they cannot replay it later to impersonate the device.

[0063] Specifically, the anonymous device identifier is generated as follows: The device first obtains the three inputs mentioned above; then, it uses a cryptographic one-way function (such as hash functions like SHA-256 or SHA-3, or the HMAC algorithm based on hashes) to process the three inputs according to predetermined rules (such as concatenation or HMAC mixing first); the output of this one-way function is the anonymous device identifier used in this case.

[0064] In this embodiment, by introducing a time factor and combining it with a one-way function to generate anonymous identifiers, dynamics and timeliness are injected into device identity, so that the same device will generate different identifiers at different sessions or time points, thus breaking the long-term behavior tracking chain.

[0065] Based on any of the above embodiments, before sending the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification terminal, the method further includes: Generate an asymmetric key pair based on the aforementioned underivative root key; The public key portion of the asymmetric key pair is determined as the public key.

[0066] It should be noted that this embodiment introduces a key derivation and isolation layer, instead of directly using the root key pair of the hardware security module for communication signing. This helps to enhance the security and flexibility of the system.

[0067] The root key is the highest level of trust anchor for a device, and its direct use should be minimized. By deriving a session key or application key pair to perform specific signing operations, even if the private key of this derived key is at risk due to algorithmic vulnerabilities, the root key itself will not be directly compromised, thus achieving isolation of security risks.

[0068] Specifically, the generation of asymmetric key pairs is performed within the hardware security module. The device instructs the module to create a new asymmetric key pair (e.g., RSA-2048 or ECC P-256 key pair) using a non-derivative root key as the security seed or master key, through a standard key generation or derivation algorithm. The newly generated private key is also stored internally within the module, and its non-derivative property is inherited from the root key or guaranteed by the module's policy. The device retrieves the public key portion of the newly generated key pair from the module and sends it, along with the anonymous device identifier, to the verification end as the public key.

[0069] In this embodiment, by deriving temporary asymmetric key pairs based on the non-derivative root key within the hardware security module for communication, secure isolation and fine-grained management of key usage are achieved. This maintains a strong association with the hardware root of trust while reducing the risk of direct exposure of the root key.

[0070] Based on any of the above embodiments, the challenge information is a one-time random number generated by the verification end.

[0071] It should be noted that a one-time random number means that the random number is only valid within the specific verification session. Once the verification process ends (whether successful or not), the random number is discarded and will not be reused.

[0072] As an example, a random number refers to a block of data generated by a cryptographically secure random number generator at the verification end, which has a high entropy value, is statistically uniformly distributed, and is unpredictable. Its length must meet preset cryptographic security requirements (e.g., at least 128 bits or 16 bytes).

[0073] In this embodiment, the challenge information is limited to a one-time random number to prevent session replay attacks. Even if an attacker eavesdrops on the data of a previous complete session (including the anonymous device identifier, public key, challenge random number C1, and signature response S1), they cannot successfully impersonate the device in subsequent sessions. This is because when an attacker attempts to initiate a new impersonation session, the verification end generates a different random number C2. The attacker cannot use the old signature S1 to respond to the new challenge C2 (signature verification will fail); if the attacker attempts to replay the old C1, the verification end will reject the request because C1 is not a one-time random number generated this time.

[0074] In this embodiment, by limiting the challenge information to a one-time random number generated by the verification end, the uniqueness of each authentication session is ensured, thereby preventing replay attacks.

[0075] Based on any of the above embodiments, the device hardware features include at least one of the following: a central processing unit serial number, a platform configuration register value of a trusted platform module, and endorsement key information of the hardware security module.

[0076] It should be noted that the central processing unit serial number is a globally unique identifier that is either melted down or written into the main CPU chip of the device during the production stage.

[0077] Ideally, each physical CPU chip has a unique central processing unit serial number, which is one of the lowest-level hardware identities of the device. Using this as an input factor, the generated anonymous identifier can be directly bound to the specific physical chip that hosts the computing core.

[0078] The Platform Configuration Register (PCR) value of the Trusted Platform Module (TPM): The Platform Configuration Register is a special set of registers within the TPM used to store hash values ​​of hardware and software components (such as BIOS, bootloader, operating system kernel, etc.) measured during system startup. Changes in system state are reflected in the PCR value in real time through extended operations. The PCR value is a cryptographic digest of the platform's hardware and software configuration and startup sequence, representing the device's "trusted state" at a given moment. Although the PCR value itself changes, its value is deterministic during specific phases when the device is operating stably and has not been maliciously tampered with (such as after trusted boot is completed). By using the Platform Configuration Register value of the Trusted Platform Module as input, an anonymous identifier can be bound not only to the hardware but also to a known, trusted software state of the device. The integrity of the PCR value's measurement and storage is guaranteed by the TPM hardware, and it cannot be directly forged externally. Although the platform does not know which specific PCR value it is, it knows that the value originates from a genuine measurement process protected by the TPM.

[0079] The endorsement key information of the hardware security module: The endorsement key is a pair of asymmetric keys (or its public key and certificate) injected by the TPM manufacturer during chip production, serving as the TPM chip's "factory ID card." This information typically refers to the hash value of its public key, certificate digest, or other verifiable derived identifiers. The EK is the root identity of the TPM chip, possessing extremely high uniqueness and authority (endorsed by the manufacturer). Using EK information as input allows anonymous identifiers to be directly anchored to specific, manufacturer-certified hardware security module entities. Directly using the complete EK certificate may leak information such as manufacturer and model. Therefore, its hash value or anonymous credentials derived from it can be used as input to protect privacy while leveraging its uniqueness.

[0080] Understandably, the CPU serial number, the platform configuration register value of the trusted platform module, and the endorsement key information of the hardware security module provide multi-dimensional information such as uniqueness, trusted status, and hardware root identity, which together ensure that the generated anonymous device identifier can both hide the true identity of the device and represent this specific and known physical device in an unforgeable manner, thus laying a solid and reliable physical foundation for subsequent anonymous verification.

[0081] In this embodiment, multiple reliable and tamper-resistant hardware dimensions for anchoring anonymous identifiers to specific physical devices are defined, ensuring that the generated anonymous identifiers have strong device uniqueness and providing a feasible basis for one device, one secret key.

[0082] Based on any of the above embodiments, the hardware security module is a trusted platform module or a trusted execution environment.

[0083] It should be noted that the Trusted Platform Module (TPM) is a standalone security cryptographic processor, typically existing on the motherboard as a physical chip (discrete TPM) or in firmware form (firmware TPM). It is a dedicated coprocessor separate from the main CPU.

[0084] The reason why the trusted platform module was chosen in this embodiment is because: Physically isolated storage and computation: its key generation, storage and cryptographic operations are all completed inside the chip, isolated from the host system, and naturally have the logical attribute of "non-exportable"; A complete key management system: It provides a key hierarchy structure, which can generate and securely store key such as endorsement keys and root keys, and meets the requirement that the root key cannot be derived. Platform integrity measurement: It has mechanisms such as PCR and can provide device hardware characteristics (such as PCR value).

[0085] Trusted Execution Environment (TEE): This is created by the main processor (such as CPU or SoC) using hardware isolation technologies (such as ARM TrustZone, Intel SGX, AMD SEV).

[0086] The trusted execution environment was chosen in this embodiment because: Hardware-enforced logical isolation: Through the CPU's hardware mechanism, isolated memory and execution space are provided for security applications (TA), ensuring that the code and data (including the root key) are invisible and inaccessible even to the host operating system, thus achieving non-exportability; High performance and integration advantages: Since it shares a chip with the main processor, cryptographic operations do not need to go through an external bus, resulting in higher performance and better integration, making it suitable for size- and power-sensitive devices; Flexible software-defined security: Within the TEE, all security-sensitive operations such as key management, identifier generation, and signing can be implemented by writing specific trusted applications, providing a high degree of customization flexibility.

[0087] It should be understood that TPM is particularly suitable for scenarios with extremely high security requirements, strict compliance requirements (such as government and financial industries), or where the device design allows for the integration of a separate security chip.

[0088] TEE is particularly suitable for consumer electronics and IoT devices with higher requirements for cost, power consumption, and integration, as well as scenarios that require high-performance and secure computing.

[0089] In this embodiment, the hardware security module can be implemented based on either TPM or TEE, two standardized hardware security technologies, to cover different device types ranging from standalone security chips to integrated security zones.

[0090] Furthermore, embodiments of this application also provide a device anonymity verification system, the system comprising: On the device side, it is used to obtain the anonymous device identifier and send the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification end. The anonymous device identifier is generated based on the non-derivative root key in the hardware security module of the device side and the device hardware characteristics. The verification terminal is used to receive the anonymous device identifier and the public key, and send challenge information to the device terminal; The device is also used to receive the challenge information, sign the challenge information using the non-derivative root key to obtain a signature response, and send the signature response to the verification end. The verification terminal is also used to verify the signature response based on the public key to complete anonymous verification for the device.

[0091] It should be noted that the verification end refers to the entity that provides verification services, such as cloud service platforms, edge management platforms, and authentication servers. The verification end is responsible for verifying and challenging anonymous credentials from the device.

[0092] Specifically, the device acquires or generates a public key associated with the anonymous device identifier and root key, then encapsulates the anonymous device identifier and public key into a registration request and sends it to the verification end. The verification end receives the registration information from the device, extracts the anonymous device identifier and public key, and establishes a temporary session context internally. For this session, a one-time random number is generated as challenge information and sent to the corresponding device. Then, the verification end receives the signed response from the device, uses the previously received public key to perform cryptographic verification on the signed response, and checks whether it is a valid signature of the issued challenge information. If the signature verification passes, it means that the device has successfully proven that it possesses a hardware-protected private key matching the registered public key and is a legitimate device responding to challenges in real time. At this point, the verification end completes the anonymous verification for that device. Throughout the entire process, the verification end makes judgments solely based on the anonymous identifier and cryptographic credentials, and does not rely on or know the true identity of the device.

[0093] In this embodiment, anonymous verification based on hardware root of trust is achieved through clear division of labor and interaction on the terminal side.

[0094] Based on any of the above embodiments, the verification terminal is further configured to determine the device terminal corresponding to the anonymous device identifier as a legitimate device if it is determined that the signature response based on the public key has been verified as legitimate.

[0095] It should be noted that identifying a device as a legitimate device grants it a new, temporary, and authorized logical identity. This means that the device corresponding to the anonymous device identifier has been granted permission to initiate subsequent interactions or access resources controlled by the verification end during the validity period of this verification session.

[0096] As an example, the legitimate status of a device can be associated with a session token, access token, or internal policy to enable the system to track and manage the lifecycle of each anonymous session.

[0097] In this embodiment, by marking the device as a legitimate device, the state transition from successful verification to authorization is achieved. Only legitimate devices can access subsequent resources and services, thereby achieving manageability in an anonymous environment.

[0098] Based on any of the above embodiments, the verification end is further configured to, upon determining that the signature response verification based on the public key has passed, derive an encryption resource and container policy based on the anonymous device identifier, and create a target container bound to the anonymous device identifier, wherein the target container is used to process data from the device end corresponding to the anonymous device identifier based on the encryption resource.

[0099] It should be noted that this embodiment illustrates how, after successful anonymous verification, the verification end transforms a one-time, anonymous trust verification into a persistent computing service instance with strong security isolation.

[0100] Encrypted resources refer to cryptographic materials dynamically generated for this session to protect data. Optionally, the encrypted resources include: Volume encryption key: Used to transparently encrypt the storage volume to be allocated to the container (such as using LUKS, eCryptfs) to ensure encrypted data persistence; Network session key / configuration seed: Used to generate unique network identifiers (such as VXLAN VNI), IP addresses, or tunnel keys to achieve logical isolation at the network layer.

[0101] Container policy: A set of rules that controls the runtime behavior of containers. Optionally, the container policy includes: resource quotas (CPU / memory), security context (SELinux / AppArmor tags), accessible network policies, allowed volumes, etc.

[0102] Derivation Mechanism: The verification end uses the anonymous device identifier as the unique master key and derives the aforementioned resources and policies through a key derivation function (such as HKDF) or a configuration template. This ensures that different devices receive completely different resources, and that these resources can only be reproduced from this anonymous identifier.

[0103] Understandably, creating a target container bound to the anonymous device identifier means that the container instance's lifecycle, security context, and data processing capabilities are logically and cryptographically exclusive to that anonymous device identifier. As an example, this binding is achieved by injecting the derived volume encryption key only into the container, configuring its network namespace using a derived network seed, and embedding the anonymous identifier's handle in the container's environment variables.

[0104] Target container: An instantiated, OCI-compliant container (such as a Docker container) or a more general isolated execution environment (such as a Kata container or a gVisor sandbox). The target container is the carrier that runs the actual business application.

[0105] The target container is used to process data from the device corresponding to the anonymous device identifier based on the encrypted resources. In other words, the target container only processes data streams from the physical device corresponding to the anonymous device identifier it is bound to. During processing, the target container needs to use encrypted resources derived from it (such as decrypting data with a volume key and establishing secure communication with a network key).

[0106] In this embodiment, after successful verification, the verification end dynamically derives resources based on the anonymous identifier and creates a strongly bound container, realizing the delivery from anonymous authentication to dedicated secure computing resources and constructing a strongly isolated data closed loop of one device, one container, and one key.

[0107] Furthermore, this application also provides a system and method for device fingerprint anonymous authentication and container strong binding. This system and method for device fingerprint anonymous authentication and container strong binding has the same inventive concept as the device anonymous verification method, system, electronic device, storage medium and program product described in any of the above embodiments.

[0108] In this embodiment, the system architecture is as follows: Figure 4 As shown, it mainly includes the following two functional sides: Device-side security subsystem: The device integrates a TPM / TEE module with a non-derivative root key K_d, supporting anonymous pseudonymous PIDs (Anonymous Faked PID, referring to an attempt to spoof or deceive a process identifier (PID)). It generates and challenges signatures to ensure one-to-one key and identity confidentiality.

[0109] Platform-side zero-knowledge subsystem: The system includes a device registration module, which supports the challenge module to verify the consistency between the device signature and PID, and derives a key based on the verification result, injecting it into volume, network and environment policies to achieve the purpose of strong binding without identity, thereby generating the container corresponding to the device.

[0110] In the system, each module operates according to the following process: Step 1: Equipment PID Generation: Within the TEE, the device takes a non-derivative root key K_d, multi-factor hardware characteristics F_dev (such as CPU serial number, TPMPCR value, etc.), and the current timestamp epoch as input, and generates a device anonymized pseudonym PID using a one-way function (such as HMAC or KDF). This PID has the following characteristics: The true identity of the device cannot be irreversibly deduced; The same device can generate different PIDs at different times (it has time-sensitivity). It can be used for subsequent signature verification and key derivation.

[0111] Step 2: Anonymously register the device to the cloud platform: The device initiates a registration request to the platform using the generated PID and its corresponding public key (derived from K_d). The platform does not store any recoverable device identity information, but only records the mapping relationship between the PID and the public key to ensure the anonymized representation of the device.

[0112] The registration process is as follows: 1. The platform sends a one-time random number challenge (nonce) to the device; 2. The device uses K_d to sign the nonce within the TEE; 3. The device will send the signature result and PID back to the platform together; 4. The platform uses a public key to verify the validity of the signature and to verify the binding relationship between the PID and the public key; 5. Upon successful verification, the platform immediately generates the following resources: Volume key: used to encrypt user data uploaded by the device; Network drift seed: used to generate dynamic network configurations to prevent network fingerprinting; Environment variable handle: injected into the container runtime environment to ensure policy consistency.

[0113] 6. The platform creates a dedicated container for each device, completing a one-to-one binding between the device and the container; 7. The platform adopts a two-layer key model: the lifetime volume master key K_vol is responsible for data encryption, and the rotation key encryption key KEK is hot-loaded as the PID changes, so as to achieve the purpose of key rotation and policy update without rebuilding the container.

[0114] Step 3: Data Upload and Container Execution Devices upload user data by binding to containers. All data is encrypted using a volume key before uploading. Platform-side containers can only decrypt data from the corresponding device, ensuring data isolation and confidentiality. The container runtime environment is controlled by platform policies to prevent containers from being migrated or copied.

[0115] In practical implementation, the method can be applied to the design of products and systems that require privacy protection of device identity and device information, while also needing to link with cloud platforms.

[0116] The method provides a device anonymity authentication and container strong binding method based on a TPM non-derivative root key. It completes the "device-side anonymity identity generation" and "platform-side unidentified strong binding container creation" in two steps, as detailed below. Figure 5 As shown. Step 1: Anonymous PID generation on the device side (one device, one password, identity untraceable): Step 1.1: The TPM chip generates an RSA-2048 root key pair K_d internally and sets fixedTPM=1 to ensure that the private key cannot be exported or migrated. Step 1.2: The TEE trusted application reads the following hardware characteristics: CPU unique serial number CPU_ID; TPM endorsement key public key digest TPM_EK; timestamp calibration value epoch (1ms precision, to prevent replay). Step 1.3: Calculate the one-time anonymous pseudonym within the TEE: PID=SHA256(K_d_private||CPU_ID||TPM_EK||epoch); Step 1.4: The TEE delivers the RSA public key corresponding to PID and K_d to the device user space. The original terminal side does not save any recoverable identity.

[0117] Step 2: Creation of a platform-side container with no identity and strong binding: Step 2.1: The device registers with the platform through the TLS channel, sending only the following message: {"pid":"did:pid:7b8c9d…","pub":RSA_Pub_K_d} without any MAC, SN, or certificate extension information.

[0118] Step 2.2: The platform generates a 32-byte random number N and returns it as a challenge.

[0119] Step 2.3: The device uses K_d_private within the TEE to perform PKCS#1v1.5 signature on N and returns the signature value S.

[0120] Step 2.4: The platform uses Pub to verify signatures. Once the verification is successful, the device is considered legitimate and no additional identity fields are recorded.

[0121] Step 2.5: The platform generates the policy key in memory in real time (without writing it to disk or caching it): volKey=HKDF(PID,"vol",32) / / Used for LUKS volume encryption; driftSeed=HKDF(PID,"net",16) / / Used to generate dynamic VXLANVNI to prevent network fingerprinting; PID_HANDLE=PID[0:8] / / Container environment variable handle, used for runtime policy indexing; The platform synchronously adopts a two-layer key model: the lifetime volume master key K_vol is responsible for data encryption, and the rotating KEK only repackages the K_vol ciphertext, so the container does not need to be rebuilt.

[0122] Step 2.6: The edge node immediately performs the following atomic operations to complete the strong binding without identity: a) Create an encrypted volume pvc-{PID_HANDLE} where only this container knows the key. cryptsetup luksFormat / dev / loop0 --key-file<(echo volKey); b) The container startup script injects PID_HANDLE into the application, which then retrieves the volKey from memory based on this. The volume key is not entered into the environment variables or mounted.

[0123] docker run -v pvc-{PID_HANDLE}: / data -e PID_HANDLE={PID_HANDLE} --name cnt-{PID_HANDLE} lock-control-app; Step 2.7: Before the device uploads data, it encrypts the data stream using a temporary symmetric key negotiated in the same TLS session. After receiving the data, the platform decrypts it using volKey within the container and writes it to / data, thus achieving a closed loop of device encryption and container decryption.

[0124] In this embodiment, the PID is decoupled from the real hardware identifier, making it impossible to deduce the CPU_ID or TPM_EK in reverse. The PID changes dynamically across different epochs for the same device, achieving forward anonymity. This solves the problems of device identity leakage and tracking: the platform only knows the one-time PID throughout the process, without storing static identifiers such as CPU_ID, MAC, and certificates, achieving zero-knowledge registration of devices; the PID is refreshed with each epoch during cold start, and old PIDs cannot be associated with new sessions, thus blocking long-term tracking and meeting privacy compliance. It also addresses the risks of insecure device-container binding and data leakage during migration: using a "lifetime K_vol + rotating KEK" two-layer key technology, even if the container is snapshotted or migrated, the K_vol cannot be desealed due to the lack of a KEK, naturally preventing snapshot copying attacks and lateral movement. The implementation process is as follows: K_vol remains unchanged throughout life → the data encryption key is constant; KEK rotates with the PID → the LUKS header is re-encapsulated, eliminating the need for rebuilding container instances and volume file systems, and enabling zero-migration. This solution addresses the issues of complex key management and susceptibility to privilege escalation. The root key K_d never leaves the TPM; the plaintext K_vol exists only in container memory, with a lifespan equal to or less than the container's runtime; KEK rotation never writes plaintext to disk, ensuring no files can be copied and no environment variables can be leaked, and the key lifespan can be reset with a single click. It also solves the problem of platforms being unable to verify identity authenticity. Through a challenge-response mechanism between the device and the platform, it utilizes the non-exportable private key signature feature within the TPM. The platform verifies the signature using only the RSA public key, achieving zero-knowledge verification of the true hardware root. When the PID changes, verification can continue by "re-encapsulating the same K_vol," without needing to store any static identity, thus balancing anonymity and trustworthiness.

[0125] Based on the methods described in any of the above embodiments, this application also provides, as follows: Figure 6 The diagram shows the structure of an electronic device. Figure 6 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to implement the methods described in any of the above embodiments.

[0126] Based on the methods described in any of the above embodiments, this application also provides a computer storage medium storing a computer program, which, when executed by a processor, can be used to perform the methods described in any of the above embodiments.

[0127] Based on the methods described in any of the above embodiments, this application also provides a computer program product, which includes one or more computer programs or instructions. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. When executed by a processor, the computer program implements the methods described in any of the above embodiments.

[0128] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0129] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

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

[0131] The above description is merely an embodiment of this application and is not intended to limit the scope of protection 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 protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0132] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for anonymous device verification, characterized in that, The method is applied to the device; the method includes: Obtain the anonymous device identifier, which is generated based on the non-derivative root key in the hardware security module of the device and the device hardware characteristics; Send the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification terminal; Receive challenge information from the verification terminal; The challenge information is signed using the non-derivative root key to obtain a signed response; The signature response is sent to the verification terminal, so that the verification terminal verifies the signature response based on the public key to complete the anonymous verification of the device.

2. The method according to claim 1, characterized in that, The anonymous device identifier is generated based on a one-way function of the non-derivative root key, the device hardware characteristics, and a time factor.

3. The method according to claim 1, characterized in that, Before sending the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification terminal, the method further includes: Generate an asymmetric key pair based on the aforementioned underivative root key; The public key portion of the asymmetric key pair is determined as the public key.

4. The method according to any one of claims 1-3, characterized in that, The challenge information is a one-time random number generated by the verification terminal.

5. The method according to claim 1, characterized in that, The device hardware features include at least one of the following: the central processing unit serial number, the platform configuration register value of the trusted platform module, and the endorsement key information of the hardware security module.

6. The method according to claim 1, characterized in that, The hardware security module is a trusted platform module or a trusted execution environment.

7. A device anonymity verification system, characterized in that, The system includes: On the device side, it is used to obtain the anonymous device identifier and send the anonymous device identifier and the public key corresponding to the anonymous device identifier to the verification end. The anonymous device identifier is generated based on the non-derivative root key in the hardware security module of the device side and the device hardware characteristics. The verification terminal is used to receive the anonymous device identifier and the public key, and send challenge information to the device terminal; The device is also used to receive the challenge information, sign the challenge information using the non-derivative root key to obtain a signature response, and send the signature response to the verification end. The verification terminal is also used to verify the signature response based on the public key to complete anonymous verification for the device.

8. The system according to claim 7, characterized in that, The verification terminal is further configured to, upon determining that the signature response verified based on the public key has passed verification, identify the device terminal corresponding to the anonymous device identifier as a legitimate device.

9. The system according to claim 7, characterized in that, The verification end is further configured to, upon determining that the signature response verified based on the public key has passed verification, derive encryption resources and container policies based on the anonymous device identifier, and create a target container bound to the anonymous device identifier. The target container is used to process data from the device end corresponding to the anonymous device identifier based on the encryption resources.

10. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements the method according to any one of claims 1-6.

11. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of any of the methods described in claims 1-6.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images