A collaborative asset management system based on end-to-end encryption

Abstract

This invention relates to the fields of information security and computer software technology, and discloses a collaborative asset management system based on end-to-end encryption, employing a zero-knowledge architecture with client-server collaboration. The client creates a collaborative space and generates a space key. For sensitive credentials, it generates a content key to form credential ciphertext and content key encapsulated ciphertext. During access, a controlled-use proxy decapsulates the content key encapsulated ciphertext in a local controlled execution environment to obtain the content key, completing controlled credential use and thus preventing the plaintext credential from being exposed to external programs. The server stores the space key encapsulated ciphertext, credential ciphertext, content key encapsulated ciphertext, and directory and policy information. Through a proxy re-encryption (ciphertext domain conversion) module, the space key encapsulated ciphertext is converted into ciphertext that new members can decapsulate without decrypting the plaintext key, enabling dynamic member addition without re-encrypting and retransmitting all credentials. The system registers capability declarations through extended module interfaces to describe heterogeneous asset access capabilities. Based on this, the client selects a connector and executes a blind injection / proxy call authentication process. At the same time, audit events are encrypted and their integrity is protected by hash chains or digital signatures. The server only stores audit ciphertext and non-sensitive index fields, thereby achieving collaborative management, controllable use, and scalable access under zero-knowledge conditions.

Description

Technical Field

[0001] This invention relates to the fields of information security, zero-trust architecture, and computer software technology, specifically to a collaborative asset management system based on end-to-end encryption. Background Technology

[0002] With the increasing distribution of enterprise operation and maintenance environments, protecting sensitive credentials such as SSH keys, database passwords, and API access tokens has become a core security requirement. In multi-user collaborative scenarios, an ideal asset management system needs to simultaneously meet the requirements of confidentiality, the principle of least privilege, auditability, and extremely low operation and maintenance costs. However, existing technical solutions generally suffer from the following shortcomings when dealing with the contradiction between "collaborative management efficiency" and "trust boundaries": 1. End-to-end encryption solutions suffer from a management gap: "can store, but cannot manage." While existing end-to-end encrypted credential management solutions offer advantages in privacy protection, achieving "client-side encryption and decryption, server-side non-decryption," their functional boundaries are often limited to the static sharing and storage of credentials. They suffer from serious deficiencies in heterogeneous asset cataloging, in-depth access path control, and audit loop closure, making it difficult to transform "shared secrets" into "controlled access," thus failing to form a closed-loop business model for asset management.

[0003] 2. Centralized access control solutions face a trade-off between security and convenience. While traditional centralized solutions such as bastion hosts provide a unified entry point and session auditing, their architecture requires the server to possess or have access to plaintext versions of sensitive information, leading to significant centralized trust risks and an expanded attack surface. Furthermore, such systems are typically cumbersome and complex to deploy, resulting in extremely high collaboration costs and operational burdens for teams seeking rapid response and lightweight maintenance.

[0004] Therefore, the industry urgently needs a collaborative asset management system that can simultaneously achieve collaborative credential management, asset access control, and security auditing without the server accessing the plaintext of sensitive credentials. Summary of the Invention

[0005] To address the aforementioned technical issues, this invention proposes a collaborative asset management system based on end-to-end encryption. This system adopts an architecture where the client and server work together, and achieves unified management of sensitive credentials, asset access, and audit records through end-to-end encryption mechanisms, collaborative authorization mechanisms, and controlled usage agents.

[0006] In this system, the client is used to create a collaborative space and generate a space key bound to the collaborative space; generate a content key for each sensitive credential, encrypt the sensitive credential using the content key to form credential ciphertext; encapsulate the content key using the space key to form content key encapsulated ciphertext; and upload the credential ciphertext, the content key encapsulated ciphertext, and related asset catalog information to the server for storage and management.

[0007] The server is used to maintain the relationships between members of the collaborative space, access control policies, and asset catalog information, and to store and manage the encrypted data uploaded by the client. The server adopts a zero-knowledge architecture, meaning that the server only stores the encrypted space key, encrypted credentials, encrypted content key, and asset catalog information, and does not possess private key materials or equivalent key materials that could obtain the space key, content key, or plaintext sensitive credentials, thereby avoiding the security risks caused by the server's access to plaintext sensitive credentials.

[0008] During the authorization process for collaborative members, when a new member joins the collaborative space, the encrypted space key can be converted through a proxy re-encryption mechanism. This allows the new member to decrypt the space key locally, thereby enabling dynamic authorization of collaborative permissions and avoiding the need to re-encrypt and distribute all sensitive credentials one by one, thus improving the efficiency of collaborative authorization.

[0009] During asset access, the client establishes a controlled access channel through a controlled proxy, decapsulates the ciphertext of the content key locally to obtain the content key, and uses the content key to decrypt the ciphertext of the credentials to obtain the plaintext of the sensitive credentials or to obtain short-term session access credentials, so as to complete the access to the target asset without directly exposing the plaintext of the sensitive credentials.

[0010] Furthermore, the system supports access to different types of assets through extended module interfaces and adapts access protocols for different types of assets through connectors, thereby achieving unified access control and management for multiple asset types.

[0011] In terms of auditing, the client collects audit events during asset access and uploads them to the server for storage after encryption. The server only stores the audit ciphertext and non-sensitive index information, thereby enabling the storage and retrieval of audit records without obtaining the plaintext audit content.

[0012] Through the above technical solution, the present invention aims to provide a technical architecture for achieving a closed loop of collaborative asset management under the premise of zero knowledge on the server side, thereby realizing unified management of credential collaborative management, asset access control and audit records.

[0013] Beneficial effects Compared with the prior art, the present invention has at least the following beneficial effects: 1. Server-side zero-knowledge security architecture: This invention uses an end-to-end encryption mechanism to ensure that sensitive credentials are decrypted and used only on the client side. The server does not have the ability to decrypt the plaintext credentials, thereby significantly reducing the security risks brought about by centralized storage.

[0014] 2. Improved collaboration authorization efficiency: This invention enables dynamic authorization of collaboration members through a proxy re-encryption mechanism, allowing new members to gain access without re-encrypting all credentials, thereby improving collaboration efficiency and reducing key management costs.

[0015] 3. Controlled asset access mechanism: This invention enables third-party applications to complete authentication and access without obtaining plaintext credentials by using a controlled proxy on the client side, thereby reducing the risk of sensitive credential leakage.

[0016] 4. Unified management capability for multiple asset types: This invention enables unified access and management of different types of assets through extended module interfaces, allowing the system to support multiple asset access protocols and realize centralized configuration, execution and auditing of policies under a unified access control policy framework.

[0017] 5. Security Audit Mechanism: This invention encrypts audit events on the client side and combines them with an integrity protection mechanism, enabling the system to store and retrieve audit records without exposing plaintext audit data, thereby improving the security of audit data. Attached Figure Description

[0018] Figure 1 This is a diagram showing the overall topology of the system of the present invention; Figure 2 Authorization flowchart based on proxy re-encryption in the scenario of adding new members; Figure 3 This is a schematic diagram of the credential blind injection logic based on capability declaration. Detailed Implementation

[0019] To make the technical solution of the present invention clearer, the present invention will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are only used to illustrate the present invention and not to limit the scope of protection. Various modifications and substitutions can be made by those skilled in the art without departing from the concept of the present invention.

[0020] Example 1: Collaboration space creation, key encapsulation, and encrypted credential storage like Figure 1 , Figure 2 As shown, in one embodiment, the client creates a collaborative space and generates and uploads the encrypted key and credentials. The specific steps are as follows: Collaboration space initialization and space key generation. When a client creates a collaboration space, it generates a space key that is bound to that collaboration space. . It can be generated by a secure random number generator; alternatively, the client can combine it with a hardware random source (such as TPM, TEE or system entropy pool) to improve randomness, but is not limited thereto.

[0021] Spatial key encapsulation and upload. The client encapsulates and uploads the spatial key. Generate spatial key-encapsulated ciphertext through public-key encryption or key encapsulation mechanisms. The space key is then encapsulated and uploaded to the server for storage; the client locally saves and decapsulates the encrypted data using encryption. The server does not store the required private key material or equivalent protection material that can be decapsulated to obtain the spatial key. Private key materials or equivalent key materials are provided to meet the zero-knowledge requirement of the server.

[0022] Sensitive credentials are encrypted and encapsulated with content keys. The client generates a content key for each sensitive credential. and using the content key Encrypt sensitive credentials to create ciphertext. Meanwhile, the client utilizes the spatial key. Content key Encapsulation is performed to form content key-encapsulated ciphertext. The encrypted credentials Encapsulated ciphertext with content key It can be uploaded to the server after being associated with non-sensitive index information such as asset identifier, version number, or update time.

[0023] Using the above method, the server only stores the ciphertext encapsulated with the space key. ciphertext Content key encapsulated ciphertext It does not possess the private key materials required for decryption, and thus it is difficult to recover the plaintext of sensitive credentials even if the server-side storage is leaked.

[0024] Example 2: Re-encryption authorization for newly added members' proxy like Figure 1 , Figure 2 As shown, in one embodiment, when a new member is added to the collaboration space, efficient authorization of the new member is achieved through proxy re-encryption, specifically including: New member joining request and authorization judgment. When a new member requests to join the collaboration space, the server receives the joining request and triggers the authorization process; the server determines whether to allow the new member to join the collaboration space based on the member relationship, access control policy and collaboration space configuration, and determines the authorization conditions such as the scope of assets allowed to be accessed, the validity period of the authorization and / or the scope of operation permissions.

[0025] The authorization side generates conversion delegation information. Upon successful authorization, at least one client with an existing authorized member generates delegation information for proxy re-encryption based on its locally held private key and the public key of the target new member. This delegation information enables the server to perform a conversion operation on the ciphertext encapsulated by the space key corresponding to the collaborative space without obtaining the plaintext space key. The delegation information can be bound to a space identifier, target member identifier, validity period, asset scope, and / or permission scope to meet policy control requirements. Specifically, the delegation information can be a proxy re-encryption delegation key, conversion token, conversion parameters, or other equivalent authorization materials.

[0026] The server performs ciphertext conversion and sends it out. Without decrypting the plaintext space key or accessing the target new member's private key material, the server performs proxy re-encryption or equivalent ciphertext conversion on the stored space key-encapsulated ciphertext based on the delegated information, generating a converted space key-encapsulated ciphertext that can be decapsulated by the target new member's client, and then sends the converted space key-encapsulated ciphertext to the target new member's client.

[0027] The newly added member obtains the space key by locally decapsulating the encrypted space key. After receiving the converted space key encrypted text, the target new member client decapsulates it locally using its private key material to obtain the space key corresponding to the collaborative space. Subsequently, the target new member client can use the space key to decapsulate the encrypted content key sent by the server to obtain the content key, and further decrypt the corresponding credential encrypted text to complete controlled access to the target assets within the authorized scope.

[0028] Using the above method, it is not necessary to re-encrypt all sensitive credentials stored in the collaborative space one by one, nor is it necessary to redistribute the corresponding credentials one by one. By simply converting the ciphertext of the space key, efficient authorization can be achieved in the scenario of adding new members, while maintaining the server's invisibility of the plaintext of the space key, the plaintext of the content key, and the plaintext of sensitive credentials.

[0029] Example 3: Method for credential decapsulation and connector access to assets in a controlled access channel like Figure 1 , Figure 3 As shown, in one embodiment, the client completes credential decapsulation and asset access through a controlled proxy within a local controlled access channel, specifically including: Authorization Request and Encrypted Text / Capability Distribution: The client initiates an access request to the server for the target asset. This access request includes at least a user identifier, a collaboration space identifier, and an asset identifier. The server determines authorization based on collaboration space membership relationships and access control policies. If authorization is successful, the server distributes to the client encrypted credentials associated with the target asset, encrypted content keys, capability statements, and session constraint parameters. If authorization fails, the server returns a failure reason or result code.

[0030] Capability Declaration Parsing and Connector Selection. For different asset types, the system registers capability declarations through an extension module interface. These declarations describe the asset protocol type, authentication method, authentication material injection method or proxy invocation method, and session constraint rules. After initiating asset access, the client selects the corresponding connector based on the asset type and capability declaration, and generates a connection process. These connectors include, but are not limited to, SSH connectors, database connectors, API connectors, or Web application connectors. Access constraints, such as the target address range, session validity period, and scope of executable operations, are limited according to the session constraint parameters.

[0031] Controlled decapsulation and controlled credential use. Within the controlled access channel provided by the controlled use proxy, the client uses a locally obtained spatial key or equivalent decapsulation material to decapsulate the ciphertext encapsulated by the content key to obtain the content key, and then uses the content key to decrypt the ciphertext to obtain the sensitive credential plaintext; subsequently: General scenario: The controlled proxy directly uses the sensitive credentials in plaintext to complete the authentication handshake and connection establishment within the controlled access channel, and the connector continues to perform access operations after the connection is established; Optional scenario: When the target asset or identity system supports this, the controlled proxy uses the sensitive credentials in plaintext to exchange for short-term session access credentials (such as short-term tokens, one-time passwords, signed responses, or session keys), and uses the short-term session access credentials only within this session to complete authentication and connection establishment, thereby further shortening the exposure window of the sensitive credentials in plaintext.

[0032] Controlled access channels and blind injection / proxy invocation. When asset access is initiated by an external access program, a controlled access proxy can provide a controlled access channel, allowing the external access program to submit a connection request through the controlled access channel. The controlled access proxy then completes the authentication and connection establishment on behalf of the external access program based on its capability statement, without directly obtaining sensitive credentials in plaintext. The controlled access channel includes at least one of the following: SSH authentication proxy channel, database connection proxy channel, API token proxy channel, and Web application authentication and session proxy channel.

[0033] Plaintext isolation, cleanup, and audit triggering. Preferably, sensitive credentials in plaintext only exist briefly within the controlled access channel, and external processes or ordinary applications cannot directly read this plaintext. When the session ends or terminates abnormally, the controlled proxy cleans up the sensitive plaintext in memory and performs session resource reclamation to reduce the risk of leakage. Furthermore, the client collects audit events at nodes such as session start, session end, authentication failure, or policy rejection, and uploads the audit events to the server for storage after encryption and integrity protection as described in Example 4.

[0034] Example 4: Encryption and Integrity Protection of Audit Events like Figure 1 As shown, in one embodiment, the client collects and encrypts key events during asset access and uploads them. The server stores and retrieves the data without decrypting the audit content. Specifically, this includes: Audit data collection. The client collects audit events at at least the following event nodes: authorization request, authorization decision result, conversion of ciphertext encapsulated in the spatial key, session start, session end, failure reason or result code, etc. Audit events must include at least the following fields: user identifier, asset identifier, timestamp, operation type, and result, among which sensitive fields and non-sensitive index fields can be distinguished.

[0035] Client-side encryption and upload: The client uses the audit public key or audit group public key to encrypt the sensitive payload of the audit event to form audit ciphertext, and uploads the audit ciphertext and non-sensitive index fields to the server; the server only stores the audit ciphertext and non-sensitive index fields, and does not hold the corresponding audit private key materials, thus it does not have the ability to decrypt the audit content.

[0036] Integrity protection and searchable management. The client performs integrity protection processing on the audit event sequence. This integrity protection processing includes, but is not limited to: calculating a hash for each audit event and forming a hash chain with the hashes of preceding events, and / or digitally signing the audit event or its digest; and suppressing the replay of audit records through mechanisms such as sequence numbers, random numbers, or timestamp windows. The server retrieves, archives, and manages audit records based on the non-sensitive index fields, completing the storage and retrieval of audit data without decrypting the audit content.

[0037] The above embodiments are only used to illustrate the technical solutions of the present invention. Any equivalent substitutions or improvements made to the above embodiments based on the concept of the present invention should fall within the protection scope of the present invention.

Claims

1. A collaborative asset management system based on end-to-end encryption, characterized in that: The client is used to create collaborative spaces and generate space keys bound to those collaborative spaces. The spatial key is encapsulated to form a spatial key encapsulated ciphertext and uploaded to the server; a content key is generated for each sensitive credential, the sensitive credential is encrypted using the content key to form a credential ciphertext, and the content key is encapsulated using the spatial key to form a content key encapsulated ciphertext corresponding to the credential ciphertext; When performing asset access, the content key is decapsulated in the client's controlled access channel to obtain the content key, and the content key is used to decrypt the credential ciphertext and complete the asset access operation. The server is used to store the space key encapsulated ciphertext, the credential ciphertext, the content key encapsulated ciphertext corresponding to the credential ciphertext, and the asset catalog information; The system manages the permissions and access policies of members in the collaborative space; and sends encrypted data related to the collaborative space to the client when the authorization policy is satisfied. The system adopts a zero-knowledge architecture, and the server does not hold private key materials or equivalent key materials for decrypting the encrypted text of the space key or the encrypted text of the content key, and therefore does not have the ability to obtain the plaintext of the space key, the content key or sensitive credentials.

2. The collaborative asset management system according to claim 1, characterized in that: The client associates the encrypted credentials with the encrypted content key and non-sensitive index information such as asset identifier, version number and / or update time, and uploads it to the server, enabling the server to complete asset catalog management and retrieval without decrypting the encrypted credentials.

3. The collaborative asset management system according to claim 1, characterized in that: The client generates a content key for each sensitive credential and uses the content key to encrypt the sensitive credential to form credential ciphertext; at the same time, it uses the space key to encapsulate the content key to form content key encapsulated ciphertext.

4. The collaborative asset management system according to claim 1, characterized in that: When a new member is added to the collaborative space, the space key is re-encrypted through a proxy mechanism to convert the ciphertext into ciphertext that can be decrypted by the new member without decrypting the space key, thereby enabling the authorization of the collaborative member.

5. The collaborative asset management system according to claim 4, characterized in that: The proxy re-encryption operation is performed on the server side, and the server side does not obtain the plaintext information of the space key or sensitive credentials during the ciphertext conversion process.

6. The collaborative asset management system according to claim 1, characterized in that: The client includes a controlled access proxy module, which is used to establish a controlled access channel locally, enabling external access programs to complete asset access without reading the plaintext of credentials.

7. The collaborative asset management system according to claim 6, characterized in that: The controlled access channel includes at least one of the following: SSH authentication proxy channel; database connection proxy channel; API token proxy channel; web application authentication and session proxy channel.

8. The collaborative asset management system according to claim 1, characterized in that: The system includes an extension module interface, which describes the access capabilities of different types of assets through capability declarations, and the client executes the asset connection process according to the capability declarations.

9. The collaborative asset management system according to claim 1, characterized in that: During the asset access process, the client collects audit events, encrypts them, and then uploads them to the server for storage.

10. The collaborative asset management system according to claim 9, characterized in that: The audit events are protected for integrity using a hash chain or digital signature mechanism, enabling the server to store and retrieve audit data without decrypting the audit content.

Images