Container data safe use method and system based on decentralized identity

Abstract

The invention discloses a container data safe use method and system based on a decentralized identity, and relates to the technical field of cloud computing security, and the method comprises the steps: generating a decentralized identity bound with a container life cycle; initiating a data use request based on the decentralized identity; identity verification is executed, and data resources are distributed based on dynamic authorization and encryption of a runtime context; and decrypting and using the data resources in the protected memory of the container. According to the method, the decentralized identity is generated on the basis of the identifier during dynamic operation of the container, and an access control mechanism in the memory is combined, so that the technical defects that the identity is unhooked from the life cycle and the plaintext is exposed in the memory during operation of the data in an existing container data security scheme are overcome.

Description

Technical Field

[0001] This invention relates to the field of cloud computing security technology, and more particularly to the field of container data security technology. Specifically, it relates to a method and system for secure use of container data based on decentralized identity. Background Technology

[0002] With the widespread adoption of cloud computing and containerization technologies (such as Docker and Kubernetes), deploying and running applications in containers has become mainstream. The lightweight, portable, and rapidly iterative nature of container technology greatly improves application delivery efficiency. However, this new technological paradigm also brings unprecedented security challenges, especially when sensitive data is used within containers; preventing data leakage has become a critical issue that urgently needs to be addressed. Currently, the technical approaches commonly used in this field mainly fall into the following three categories:

[0003] 1) Access control based on static credentials: The process involves pre-generating a static, long-term valid identity credential (such as an API Token or Service Account) for the container or Pod. The container carries this credential when requesting data, and the data provider authorizes the request after verifying the validity of the credential. The disadvantage is that the credential is static and decoupled from the container's lifecycle. Once the credential is leaked (e.g., through logs or configuration files), attackers can impersonate the container and steal data from anywhere, making it difficult to trace and revoke the authorization.

[0004] 2) Encryption during transmission and storage: The process involves encrypting data using protocols such as TLS during transmission and using static encryption features of the file system or database during data storage. The drawback is that data exists in plaintext form in the container's memory, creating a "runtime security blind spot." Attackers can directly obtain plaintext data in memory through memory dumps (such as the dd command), debugger attachments (such as GDB), container escape, and other methods.

[0005] 3) Centralized Authorization Model: The process involves all authorization requests passing through a centralized authorization server (such as an OAuth2 Server or Kubernetes API Server) for policy evaluation and ticket issuance. The disadvantages are: single point of failure and performance bottlenecks; and the central node itself is a high-value attack target, and if compromised, the entire trust system will collapse. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for secure use of container data based on decentralized identity, which solves the problems of static credential access control in the prior art. Once the credentials are leaked, attackers can impersonate the container and steal data from any location, making it difficult to trace and revoke. Data exists in plaintext in the container memory, creating a "runtime security blind spot". The centralized authorization model also suffers from single points of failure and performance bottlenecks.

[0007] The present invention solves the above problems through the following technical solution:

[0008] A method for securely using container data based on decentralized identity, comprising:

[0009] Generate decentralized identities that are bound to the container's lifecycle;

[0010] Initiate a data usage request based on decentralized identity;

[0011] Perform authentication, dynamic authorization based on runtime context, and encrypted distribution of data resources;

[0012] Decrypt and use data resources within the container's protected memory.

[0013] Furthermore, methods for generating decentralized identities that are tied to the container's lifecycle include:

[0014] The data user registers a decentralized identity and a first verifiable credential in a decentralized identity registration system; further, the first verifiable credential includes at least one of the data user's name, qualifications, or technical white paper;

[0015] The container is launched, and it generates its own decentralized identity. It issues container credentials using the private key of the data user. These credentials contain the decentralized identity of the data user and the decentralized identity of the container.

[0016] Furthermore, the process by which a container generates its own decentralized identity includes:

[0017] 1) Collect at least one of the following as dynamic information: the container's image information, runtime information, environment variables, and process tree;

[0018] 2) Generate an identity fingerprint based on the dynamic information;

[0019] 3) Derive the public and private key pair of the container based on the identity fingerprint, wherein the public key serves as the decentralized identity of the container.

[0020] The container registers itself in the decentralized identity registration system using its decentralized identity and container credentials as secondary verifiable credentials.

[0021] Furthermore, the method for initiating a data usage request based on a decentralized identity includes: the container initiating a data usage request to the data provider, the data usage request including the decentralized identity of the data user, the container's decentralized identity, and the current runtime context signed by the container's private key.

[0022] Furthermore, the current runtime context is at least one of the following: the container's image information, runtime information, environment variables, and process tree, which are collected in real time when the container initiates a data usage request.

[0023] Furthermore, methods for performing authentication, runtime context-based dynamic authorization, and encrypted distribution of data resources include:

[0024] The data provider sets an access policy for the published data resources, and the access policy is associated with the decentralized identity of the data user; furthermore, the access policy specifies at least one of the following: the decentralized identity of the authorized data user, and the image digest or key environment variables of the authorized container;

[0025] The data provider receives the data usage request from the data user and performs identity verification and runtime context authorization verification. After the verification is successful, the data resource is encrypted and sent to the data user.

[0026] Furthermore, runtime context authorization verification includes:

[0027] a) Based on the container's decentralized identity, obtain and verify the second verifiable credential from the decentralized identity registration system;

[0028] b) Verify whether the container credential in the second verifiable credential was legally issued by the decentralized identity of the data user;

[0029] c) Verify whether the current runtime context in the data use request is consistent with the initial runtime information recorded in the second verifiable credential;

[0030] d) Verify whether the decentralized identity of the data user complies with the access policy.

[0031] Furthermore, decrypting and using data resources within the container's protected memory specifically includes:

[0032] 1) The container decrypts the data resource in memory and loads the decrypted data file into a memory buffer protected by a memory locking mechanism;

[0033] 2) Intercept file access requests from business processes within the container using pre-loaded shared libraries;

[0034] 3) When the file access request points to a protected data file, data is provided directly from the memory buffer to achieve transparent access to the business process.

[0035] Furthermore, the data resources are high-fidelity simulation environment data in the embodied intelligent training scenario, including 3D model files, physical material parameter files, and texture mapping files, etc.

[0036] A container data security usage system based on decentralized identity includes:

[0037] The decentralized identity generation module is configured to generate decentralized identities that are bound to the container's lifecycle;

[0038] The secure communication module, deployed within a container, is configured to initiate data usage requests based on decentralized identities.

[0039] The authorization and data distribution module is configured to perform authentication, dynamic authorization based on runtime context, and encrypted distribution of data resources;

[0040] The secure use module, deployed within a container, is configured to decrypt and use data resources within the container's protected memory.

[0041] Furthermore, the decentralized identity generation module includes:

[0042] An entity identity management unit is used to allow data users to register a decentralized identity and a first verifiable credential in a decentralized identity registration system; further, the first verifiable credential includes at least one of the data user's name, qualifications, or technical white paper.

[0043] The container management unit is used to launch containers. Each container generates its own decentralized identity and issues container credentials using the data user's private key. These credentials contain both the data user's decentralized identity and the container's decentralized identity. Furthermore, the process of a container generating its own decentralized identity includes:

[0044] 1) Collect at least one of the following as dynamic information: the container's image information, runtime information, environment variables, and process tree;

[0045] 2) Generate an identity fingerprint based on the dynamic information;

[0046] 3) Derive the public and private key pair of the container based on the identity fingerprint, wherein the public key serves as the decentralized identity of the container.

[0047] An identity self-generation unit, deployed within a container, is used to generate a container decentralized identity and register the container decentralized identity and container credentials as a second verifiable credential in a decentralized identity registration system.

[0048] Furthermore, the secure communication module is used to initiate a data usage request to the data provider. The data usage request includes the decentralized identity of the data user, the decentralized identity of the container, and the current runtime context signed by the container's private key.

[0049] Furthermore, the current runtime context is at least one of the following: the container's image information, runtime information, environment variables, and process tree, which are collected in real time when the container initiates a request.

[0050] Furthermore, the authorization and data distribution module includes:

[0051] The policy management unit is configured to allow data providers to publish and set access policies, which are associated with the decentralized identity of data users; furthermore, the access policy specifies at least one of the following: the decentralized identity of the authorized data user, and the image digest or key environment variables of the authorized container.

[0052] The authorization verification unit is configured to, in response to a data user's data usage request, obtain and verify a second verifiable credential from the decentralized identity registration system and perform chained verification operations, including verifying the issuer of the container credential, verifying the consistency of the runtime context, and matching the access policy.

[0053] The data distribution unit is configured to, after verification, encrypt the data key using the public key corresponding to the decentralized identity of the container, and send the encrypted data key and the encrypted data resources to the container.

[0054] Furthermore, the secure usage module is configured to: decrypt data resources in container memory and load them into a protected memory buffer, and intercept file access requests through a preloaded shared library, providing and using data from the memory buffer.

[0055] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned method for secure use of container data based on decentralized identity.

[0056] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned method for secure use of container data based on decentralized identity.

[0057] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0058] (1) The present invention adopts a decentralized identity generation method based on container dynamic runtime identifier and combines it with in-memory access control mechanism to solve the technical defects of existing container data security schemes, such as the decoupling of identity and life cycle and the exposure of data in plaintext in runtime memory.

[0059] (2) The present invention achieves the unforgeability and timeliness of identity: Since the container identity is derived from its dynamic and unique runtime state, the identity cannot be copied or replayed and becomes invalid when the container is destroyed, thus fundamentally eliminating the risk of identity impersonation.

[0060] (3) This invention achieves end-to-end confidentiality protection for the entire data lifecycle: by extending the security boundary to container memory, it ensures that data is always under control or encrypted throughout the entire process of transmission, storage and use, eliminating runtime security blind spots.

[0061] (4) The present invention realizes a fine-grained dynamic security policy: the authorization decision is no longer limited to "who" is accessing, but can be based on "what operating state the container is in", realizing unprecedented security policy flexibility and accuracy.

[0062] (5) The present invention improves the robustness and scalability of the system architecture: the decentralized trust model avoids single point of failure, making the entire security system more stable and reliable, and better able to adapt to large-scale, distributed cloud-native environments. Attached Figure Description

[0063] Figure 1 This is a schematic diagram of a decentralized data collaboration architecture in an intelligent training scenario according to an embodiment of the present invention;

[0064] Figure 2 This is a schematic diagram illustrating the internal working principle of the container security module for in-memory decryption and access interception in an embodiment of the present invention. Detailed Implementation

[0065] The present invention will be further described in detail below with reference to embodiments, but the implementation of the present invention is not limited thereto.

[0066] Example 1:

[0067] A method for securely using container data based on decentralized identity, comprising:

[0068] (i) Generate decentralized identities that are bound to the container's lifecycle;

[0069] Furthermore, generating a decentralized identity bound to the container's lifecycle specifically includes:

[0070] 1. The data user registers a decentralized identity and a first verifiable credential in a decentralized identity registration system; further, the first verifiable credential includes at least one of the data user's name, qualifications, or technical white paper;

[0071] 2. Start the container. The container generates its own decentralized identity and issues a container credential using the data user's private key. This container credential contains the data user's decentralized identity and the container's decentralized identity.

[0072] Furthermore, the container generates its own decentralized identity. This step involves using the container's dynamic runtime identifier as the unique entropy source for identity generation, including:

[0073] 1) When a container starts, a daemon process collects a set of dynamic information that can uniquely identify the container instance, including but not limited to: at least one of the following as dynamic information: container runtime ID (such as Docker Container ID), image information, runtime information, environment variables (such as APP_VERSION, DEPLOYMENT_ID) and process tree (the hash value of the process tree composed of process number one and its child processes in the container);

[0074] 2) Generate an identity fingerprint based on the dynamic information: Combine the collected dynamic information into a string according to a preset serialization rule, and then use a cryptographically secure hash algorithm (such as SHA-256) to calculate it to generate a fixed-length, irreversible "container identity fingerprint".

[0075] 3) Derive the public-private key pair of the container based on the identity fingerprint: Based on the "container identity fingerprint", a key derivation function (such as the HMAC-based derivation function HKDF) is used to derive a public-private key pair. The private key is securely stored in the container's protected memory area (e.g., locked via mlock) and strict file permissions are set to prohibit any unauthorized processes from accessing it. The public key serves as the decentralized identity of the container.

[0076] 3. The container registers itself in the decentralized identity registration system using its decentralized identity and container credentials as secondary verifiable credentials.

[0077] (ii) Initiating a data usage request based on a decentralized identity. This step requires that the authentication signature of the data usage request be generated by the private key bound to the container identity.

[0078] Furthermore, the method for initiating a data usage request based on a decentralized identity includes: the container initiating a data usage request to the data provider, the data usage request including the decentralized identity of the data user, the container's decentralized identity, and the current runtime context signed by the container's private key. The steps include:

[0079] a) Constructing a request message: When a business application or proxy client within the container needs to access sensitive data, it constructs a request message. This message includes: the requested data identifier, the container's DID (i.e., the public key generated in the previous step), basic information about the requester (such as the business purpose), and a timestamp.

[0080] b) Signature request: Use the private key in the container's memory to digitally sign the entire request message.

[0081] c) Sending a request: Send the request message and digital signature together to the data provider.

[0082] Furthermore, the current runtime context is at least one of the following: the container's image information, runtime information, environment variables, and process tree, which are collected in real time when the container initiates a data usage request.

[0083] (iii) Perform authentication, dynamic authorization based on runtime context, and encrypted distribution of data resources.

[0084] The data provider sets an access policy for the published data resources, and the access policy is associated with the decentralized identity of the data user; furthermore, the access policy specifies at least one of the following: the decentralized identity of the authorized data user, and the image digest or key environment variables of the authorized container;

[0085] The data provider receives the data usage request from the data user and performs identity verification and runtime context authorization verification. After the verification is successful, the data resource is encrypted and sent to the data user.

[0086] in:

[0087] Identity verification includes: after receiving the request, the data provider uses the DID (public key) in the message to verify the validity of the digital signature to confirm that the requester does indeed hold the corresponding private key, thereby confirming their identity.

[0088] Contextual authorization includes further analysis of the request by the data provider's policy engine. The policy engine can be pre-configured with rules, such as "authorize only if the requester's container environment variable ENV=PROD". This contextual information can be carried in the request message or verified by the data provider through a secure channel querying the container's runtime environment (such as the Kubernetes API Server). Furthermore, runtime contextual authorization verification includes:

[0089] a) Based on the container's decentralized identity, obtain and verify the second verifiable credential from the decentralized identity registration system;

[0090] b) Verify whether the container credential in the second verifiable credential was legally issued by the decentralized identity of the data user;

[0091] c) Verify whether the current runtime context in the data use request is consistent with the initial runtime information recorded in the second verifiable credential;

[0092] d) Verify whether the decentralized identity of the data user complies with the access policy.

[0093] Encrypted data distribution: After authorization, the data provider generates a random symmetric key (such as an AES-256 key) and uses it to encrypt the target data. Then, the requester's DID (public key) is used to encrypt the symmetric key. Finally, the encrypted data and the encrypted symmetric key are returned to the container.

[0094] (iv) Decrypting and using data resources within the container's protected memory achieves "zero plaintext storage" and transparent access control. Specifically, this includes:

[0095] a) In-memory decryption: After receiving the encrypted data and encryption key, the security module within the container uses the container's private key to decrypt the symmetric key within a protected memory space. This symmetric key is then used to decrypt the original plaintext data, and the decrypted data file is loaded into a memory buffer protected by a memory locking mechanism. Throughout the entire decryption process, the plaintext data is never written to any disk or block device.

[0096] b) Access Interception: A custom shared library is preloaded into the business application process via the LD_PRELOAD mechanism. This library intercepts (hooks) all standard file and I / O operation functions (such as fopen, read, fgets).

[0097] c) Reference-based access: When business code attempts to read a protected file (such as / data / secret.conf), the intercepted function checks if the file is in the protected list. If so, it doesn't read from disk but directly retrieves the data from the decrypted data area in the memory buffer and returns it to the caller. This process is completely transparent to the business application and requires no code modification.

[0098] Furthermore, the data resources are high-fidelity simulation environment data in the embodied intelligent training scenario, including 3D model files, physical material parameter files, and texture mapping files, etc.

[0099] Combined with appendix Figure 1 As shown, this paper illustrates a method for securely using simulation environment data based on decentralized trust in an embodied intelligence training scenario:

[0100] The data user is a leading manufacturer of embodied intelligent robots (hereinafter referred to as the "Robot Manufacturer"). The data provider is a company specializing in creating high-fidelity physical simulation environments (hereinafter referred to as the "Simulation Environment Provider"). The Robot Manufacturer needs to use the Simulation Environment Provider's "High-Fidelity Smart Factory" simulation environment data to train the grasping and navigation strategies of its next-generation "handling robots," but the Simulation Environment Provider considers its environmental data a core asset and requires absolute confidentiality during its use.

[0101] Step S1: Data users register in the decentralized identity system

[0102] 1. Entity Identity Generation: Robot makers generate their enterprise decentralized identity, including a DID, such as did:example:robot-maker-corp, and the corresponding private key sk_platform.

[0103] 2. Create verifiable credentials: The company compiled its corporate name, industry certifications (such as ISO robot safety standards), technical white papers, and other information into a structured "identity statement".

[0104] 3. Decentralized Registration: Robot maker uses its private key sk_platform to sign the "identity claim", and then publishes this signed claim as a verifiable credential on a public decentralized identity registration system (such as a blockchain) associated with did:example:robot-maker-corp.

[0105] Step S2: The data provider publishes data resources and sets access policies.

[0106] 1. Data Preparation: The simulation environment provider packages its "High-Fidelity Smart Factory" simulation environment data (including 3D model .obj files, physical material parameters .json files, high-resolution textures .png files, etc.) into smart_factory_v4.tar.gz and encrypts it with a randomly generated AES key aes_key_simu, resulting in encrypted_simu_data.enc. Different packages are available for different data users.

[0107] 2. Publishing data resources: The simulation environment provider publishes the metadata of the data resource in its data catalog, which describes in detail the complexity of the environment, the physics engine version, etc.

[0108] 3. Configure Access Policy: The simulation environment provider sets the access policy for this resource, which is stored in its policy engine. A policy example might be: "Allow the entity with DID:did:example:robot-maker-corp to grant data access permissions to the container it launches with the image digest sha256:robot-trainer:latest..., and the environment variable TRAINING_MODEL within the container must be GraspingBot-v5."

[0109] Step S3: Data users apply for data resources

[0110] 1. Submit an application: AI engineers from robot manufacturers can find the smart_factory_v4 dataset through the portal of the simulation environment provider and submit an access application.

[0111] 2. Build the application: The application request includes the robot manufacturer's DID (did:example:robot-maker-corp) and a description of the purpose of this application (e.g., "for training complex object grasping strategies for GraspingBot-v5").

[0112] 3. Signature Sending: Sign the application request using the private key sk_platform and then send it to the simulation environment provider.

[0113] Step S4: Data provider review and verification

[0114] 1. Identity Verification: After receiving the application, the simulation environment provider uses DID to query and obtain the robot manufacturer's verifiable credentials from the decentralized identity registration system.

[0115] 2. Qualification Verification: The simulation environment provider verifies the validity of the verifiable credentials and reviews the industry certifications and technical white papers contained therein to confirm that the robot manufacturer is a legitimate and technically capable partner.

[0116] 3. Approval of application: After the application is approved, the administrator of the simulation environment provider approves the application, and the policy status related to did:example:robot-maker-corp in the policy engine changes to "activated".

[0117] Step S5: The data user starts the container and issues container credentials.

[0118] 1. Container Launch: After approval, the robot manufacturer launches a training container on its GPU server. The command could be:

[0119] docker run --name grasping-trainer -e TRAINING_MODEL=GraspingBot-v5robot-trainer:latest.

[0120] 2. Container identity self-generation: The init process inside the container collects its dynamic runtime information (image digest, container ID, environment variable TRAINING_MODEL=GraspingBot-v5, process tree hash) and generates its own DID (pk_container) and private key sk_container.

[0121] 3. Platform-issued credentials: The management agent on the host uses the robot manufacturer's private key sk_platform to generate a "container credential" vc_platform_container for the container, which constitutes the platform's trust endorsement of the container.

[0122] Step S6: The container registers in the decentralized identity system

[0123] 1. Constructing container verifiable credentials: The init process inside the container packages its own "identity statement" and the "container credentials" obtained from the platform to form a verifiable credential vc_contaniner with the container as the main body.

[0124] 2. Decentralized Registration: The init process publishes the container's verifiable credentials to a decentralized identity registration system, associating them with the container's DID (pk_container). The container's identity and runtime state are anchored to the public ledger.

[0125] Step S7: The container initiates a data usage request.

[0126] 1. Build Request: After the training script inside the container starts, its client library builds a data request message and sends it to the simulation environment provider's data access API. This message includes:

[0127] •platform_did: did:example:robot-maker-corp.

[0128] •container_did: pk_container.

[0129] •data_id: smart_factory_v4.

[0130] • container_runtime_context: Dynamic runtime information (image digest, container ID, environment variable TRAINING_MODEL=GraspingBot-v5, process tree hash).

[0131] • container_signature: The signature of all the above fields using sk_container.

[0132] Step S8: The data provider performs decentralized authorization verification.

[0133] 1. Basic verification: After receiving the request, the simulation environment provider's API first uses container_did to verify container_signature.

[0134] 2. Chain verification:

[0135] • Parse container verifiable credentials (secondary verifiable credentials): Use container_did to query and obtain the container's verifiable credentials vc_contaniner from the decentralized identity registry.

[0136] • Verify platform endorsement: Extract the “container credential” vc_platform_container from the container’s verifiable credential vc_container, and verify the platform_signature using the public key of platform_did.

[0137] • Verify state consistency: Compare the container_runtime_context in the request with the "identity claim" recorded in VC.

[0138] • Matching access policy: Check whether platform_did is authorized and whether the image digest and TRAINING_MODEL in container_runtime_context fully meet the policy requirements.

[0139] 3. Authorization Decision: After all verifications are passed, the simulation environment provider confirms the request is legitimate and authorizes it.

[0140] Step S9: Encrypted Data Distribution

[0141] 1. Key Encryption: The simulation environment provider uses the container's public key pk_container to encrypt the symmetric key aes_key_simu, resulting in encrypted_key_blob.

[0142] 2. Data transmission: The simulation environment provider returns the download address of encrypted_simu_data.enc and encrypted_key_blob to the container.

[0143] Step S10: Safe use inside the container, such as... Figure 2 As shown:

[0144] 1. Memory decryption: The security daemon inside the container uses sk_container to decrypt encrypted_key_blob to obtain aes_key_simu in protected memory, and then uses it to decrypt the downloaded dataset, loading all simulation environment files (.obj, .json, .png, etc.) into a memory buffer locked by mlock().

[0145] 2. Transparent Access: The training application uses the lib_secure_access.so library loaded by LD_PRELOAD to intercept and redirect all file access requests (such as loading factory_floor.obj), providing data directly to the application from the memory buffer.

[0146] 3. Training complete: The training script successfully loaded the entire high-fidelity factory environment into memory and began millions of grasping simulations until an optimized robot policy neural network model file, graftingbot_v5.pth, was finally generated.

[0147] Through the detailed implementation of the above ten steps, this invention successfully constructs a fully decentralized data security collaboration paradigm in the cutting-edge field of embodied intelligence. The core simulation assets of the simulation environment provider are protected end-to-end, while robot manufacturers can efficiently and transparently utilize external data resources to enhance the capabilities of their AI models. The entire process does not require trust in any third-party intermediaries; trust is entirely built on cryptography and a public ledger.

[0148] Research into existing technologies revealed the following issues: 1) Existing container identity credentials are static and cannot be bound to the container's unique and dynamic lifecycle, making identities vulnerable to forgery and abuse. The fundamental flaw is the decoupling of identity from the entity's (container's) runtime context, resulting in a weak foundation of trust. 2) Existing data protection schemes suffer from "runtime security blind spots," where data is exposed in plaintext in container memory, posing a memory leak risk. The fundamental flaw is the interruption of the security protection chain during memory access, failing to guarantee data confidentiality during use. 3) Existing authorization models overly rely on a central node, presenting single points of failure and risks of centralized trust. The fundamental flaw is a rigid trust model, resulting in insufficient system robustness and scalability.

[0149] Building upon this innovative discovery, this invention constructs a closed-loop security system across the entire container lifecycle, encompassing identity generation, dynamic authorization, and runtime access control, thereby deeply embedding security capabilities into the container's entire lifecycle. The unique design of this invention includes:

[0150] (1) The dynamic runtime identifier of the container (such as container ID, environment variable, process tree) is used as the entropy source, and a decentralized identity strongly bound to the life cycle of the container is generated through cryptographic methods.

[0151] (2) Design a runtime context dynamic authorization mechanism based on the decentralized identity so that the authorization decision can be associated with the real-time state of the container.

[0152] (3) Construct an in-memory data access control method to achieve "zero plaintext landing" and transparent controlled access of data in the container.

[0153] This invention employs a decentralized identity generation method based on dynamic runtime identifiers for containers, combined with an in-memory access control mechanism, to address the technical shortcomings of existing container data security solutions, such as the decoupling of identity from lifecycle and the plaintext exposure of data in runtime memory. It has the following advantages:

[0154] (1) The decentralized identity generated by using dynamic runtime identifiers is generated by cryptographic algorithms based on the runtime characteristics of the container itself. It is decentralized and does not rely on any central issuing authority, making the trust foundation more solid.

[0155] (2) The authorization of the data provider can be based on the dynamic context of the container runtime (such as whether specific environment variables exist or whether the process tree structure is compliant), which realizes more granular and state-dependent dynamic authorization.

[0156] (3) By using the in-memory access control mechanism, the problem of "runtime security blind spot" where data is exposed in plaintext in the container is solved, and data security is extended to the runtime usage stage in memory, thus solving the runtime security problem after data enters the container memory.

[0157] (4) Construct a decentralized trust model based on cryptography.

[0158] Example 2:

[0159] A container data security usage system based on decentralized identity includes:

[0160] The decentralized identity generation module is configured to generate decentralized identities that are bound to the container's lifecycle;

[0161] The secure communication module, deployed within a container, is configured to initiate data usage requests based on decentralized identities.

[0162] The authorization and data distribution module is configured to perform authentication, dynamic authorization based on runtime context, and encrypted distribution of data resources;

[0163] The secure use module, deployed within a container, is configured to decrypt and use data resources within the container's protected memory.

[0164] Furthermore, the decentralized identity generation module includes:

[0165] An entity identity management unit is used to allow data users to register a decentralized identity and a first verifiable credential in a decentralized identity registration system; further, the first verifiable credential includes at least one of the data user's name, qualifications, or technical white paper.

[0166] The container management unit is used to launch containers. Each container generates its own decentralized identity and issues container credentials using the data user's private key. These credentials contain both the data user's decentralized identity and the container's decentralized identity. Furthermore, the process of a container generating its own decentralized identity includes:

[0167] 1) Collect at least one of the following as dynamic information: the container's image information, runtime information, environment variables, and process tree;

[0168] 2) Generate an identity fingerprint based on the dynamic information;

[0169] 3) Derive the public and private key pair of the container based on the identity fingerprint, wherein the public key serves as the decentralized identity of the container.

[0170] An identity self-generation unit, deployed within a container, is used to generate a container decentralized identity and register the container decentralized identity and container credentials as a second verifiable credential in a decentralized identity registration system.

[0171] Furthermore, the secure communication module is used to initiate a data usage request to the data provider. The data usage request includes the decentralized identity of the data user, the decentralized identity of the container, and the current runtime context signed by the container's private key.

[0172] Furthermore, the current runtime context is at least one of the following: the container's image information, runtime information, environment variables, and process tree, which are collected in real time when the container initiates a request.

[0173] Furthermore, the authorization and data distribution module includes:

[0174] The policy management unit is configured to allow data providers to publish and set access policies, which are associated with the decentralized identity of data users; furthermore, the access policy specifies at least one of the following: the decentralized identity of the authorized data user, and the image digest or key environment variables of the authorized container.

[0175] The authorization verification unit is configured to, in response to a data user's data usage request, obtain and verify a second verifiable credential from the decentralized identity registration system and perform chained verification operations, including verifying the issuer of the container credential, verifying the consistency of the runtime context, and matching the access policy.

[0176] The data distribution unit is configured to, after verification, encrypt the data key using the public key corresponding to the decentralized identity of the container, and send the encrypted data key and the encrypted data resources to the container.

[0177] Furthermore, the secure usage module is configured to: decrypt data resources in container memory and load them into a protected memory buffer, and intercept file access requests through a preloaded shared library, providing and using data from the memory buffer.

[0178] Example 3:

[0179] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned method for secure use of container data based on decentralized identity.

[0180] Example 4:

[0181] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned method for secure use of container data based on decentralized identity.

[0182] Although the present invention has been described herein with reference to illustrative embodiments, the above embodiments are merely preferred embodiments of the present invention, and the implementation of the present invention is not limited to the above embodiments. It should be understood that those skilled in the art can devise many other modifications and implementations, which will fall within the scope and spirit of the principles disclosed in this application.

Claims

1. A method for securely using container data based on decentralized identity, characterized in that, include: Generate decentralized identities that are bound to the container's lifecycle; Initiate a data usage request based on decentralized identity; Perform authentication, dynamic authorization based on runtime context, and encrypted distribution of data resources; Decrypt and use data resources within the container's protected memory.

2. The method for secure use of container data based on decentralized identity according to claim 1, characterized in that, Methods for generating decentralized identities that are tied to the container's lifecycle include: Data users register a decentralized identity and a primary verifiable credential in a decentralized identity registration system; The container is launched, and it generates its own decentralized identity. It issues container credentials using the private key of the data user. These credentials contain the decentralized identity of the data user and the decentralized identity of the container. The container registers itself in the decentralized identity registration system using its decentralized identity and container credentials as secondary verifiable credentials.

3. The method for secure use of container data based on decentralized identity according to claim 2, characterized in that, A method for initiating a data usage request based on a decentralized identity includes: the container initiating a data usage request to the data provider, the data usage request including the decentralized identity of the data user, the container's decentralized identity, and the current runtime context signed by the container's private key.

4. The method for secure use of container data based on decentralized identity according to claim 3, characterized in that, Methods for performing authentication, dynamic authorization based on runtime context, and encrypted distribution of data resources include: The data provider sets access policies for the published data resources, and the access policies are associated with the decentralized identity of the data user; The data provider receives the data usage request from the data user and performs identity verification and runtime context authorization verification. After the verification is successful, the data resource is encrypted and sent to the data user.

5. A method for secure use of container data based on decentralized identity according to claim 4, characterized in that, Performing runtime context authorization verification includes: a) Based on the container's decentralized identity, obtain and verify the second verifiable credential from the decentralized identity registration system; b) Verify whether the container credential in the second verifiable credential was legally issued by the decentralized identity of the data user; c) Verify whether the current runtime context in the data use request is consistent with the initial runtime information recorded in the second verifiable credential; d) Verify whether the decentralized identity of the data user complies with the access policy.

6. A container data security usage system based on decentralized identity, characterized in that, include: The decentralized identity generation module is configured to generate decentralized identities that are bound to the container's lifecycle; The secure communication module, deployed within a container, is configured to initiate data usage requests based on decentralized identities. The authorization and data distribution module is configured to perform authentication, dynamic authorization based on runtime context, and encrypted distribution of data resources; The secure use module, deployed within a container, is configured to decrypt and use data resources within the container's protected memory.

7. A container data security usage system based on decentralized identity according to claim 6, characterized in that, The decentralized identity generation module includes: The entity identity management unit is used by data users to register decentralized identities and primary verifiable credentials in the decentralized identity registration system. The container management unit is used to start containers. Each container generates its own decentralized identity and issues container credentials using the private key of the data user. These container credentials contain the decentralized identity of the data user and the decentralized identity of the container. An identity self-generation unit, deployed within a container, is used to generate a container decentralized identity and register the container decentralized identity and container credentials as a second verifiable credential in a decentralized identity registration system.

8. A container data security usage system based on decentralized identity according to claim 7, characterized in that, The secure communication module is used to initiate a data usage request to the data provider. The data usage request includes the decentralized identity of the data user, the decentralized identity of the container, and the current runtime context signed by the container's private key.

9. A container data security usage system based on decentralized identity according to claim 7, characterized in that, The authorization and data distribution module includes: The policy management unit is configured to allow data providers to publish and set access policies, which are associated with the decentralized identity of data users. The authorization verification unit is configured to, in response to a data user's data usage request, obtain and verify a second verifiable credential from the decentralized identity registration system and perform chained verification operations, including verifying the issuer of the container credential, verifying the consistency of the runtime context, and matching the access policy. The data distribution unit is configured to, after verification, encrypt the data key using the public key corresponding to the decentralized identity of the container, and send the encrypted data key and the encrypted data resources to the container.

10. A container data security usage system based on decentralized identity according to claim 6, characterized in that, The secure usage module is configured to: decrypt data resources in container memory and load them into a protected memory buffer, and intercept file access requests through a preloaded shared library, providing and using data from the memory buffer.

Images