A unified password service method and system supporting cross-level sharing

Abstract

The application discloses a unified password service method and system supporting cross-level sharing, which comprises the following steps: generating a root key in a hardware security module (HSM) cluster; generating a key encryption key (KEK) in the HSM cluster based on the root key; generating a data encryption key (DEK) based on the KEK; an API gateway receives an encryption request sent by a business application, and performs identity authentication and permission authentication; a password operation service instance calls a key management service (KMS); the KMS obtains a stored corresponding encrypted DEK and an associated KEKID from a distributed database according to a target key ID; the encrypted DEK is decrypted by using the KEK corresponding to the KEKID through the HSM; the KMS encrypts plaintext data by using the plaintext DEK to obtain ciphertext data; an upper-level tenant grants access permission of a target key to a corresponding lower-level tenant through a key sharing interface, and records a sharing relationship in a key permission table; and the application fundamentally eliminates the risk of storing and exposing the plaintext key.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a unified cryptographic service method and system that supports cross-level sharing. Background Technology

[0002] With the deepening of informatization and digital transformation, data security and privacy protection have become core challenges facing various industries. Cryptographic technology, as a fundamental means of ensuring data confidentiality, integrity, and identity authentication, is widely used in finance, government affairs, healthcare, e-commerce, and other fields. However, existing cryptographic service implementations generally suffer from problems such as decentralized key management, insufficient security protection capabilities, and difficulties in cross-organizational collaboration, making it difficult to meet increasingly stringent compliance requirements and the security needs of complex business scenarios.

[0003] In current application practices, password-related requirements are mainly handled in the following two ways:

[0004] The development team directly calls existing open-source or commercial cryptographic libraries (such as OpenSSL, BouncyCastle, GnuTLS, or SDKs provided by cloud service providers) in the business code to implement encryption, decryption, and signing functions, and manages the keys themselves, typically storing them in configuration files, specific database fields, or environment variables. For example, e-commerce systems use Java's javax.crypto package to implement salted hash storage of user passwords during user registration; payment systems directly use the APIs of AWSKMS or Alibaba Cloud KMS for transaction data signing; and enterprise applications encrypt database connection strings and store them in configuration files, reading and decrypting them upon startup.

[0005] Deploying independent physical or virtual HSM (Hardware Security Module) devices allows business systems to directly call the APIs provided by the HSM for cryptographic operations and key management via network interfaces (such as PCIe, USB, or TCP / IP). This approach typically requires custom driver development or the use of a proprietary SDK provided by the device manufacturer. For example, a bank's core system deploys Thales / GemaltonShield HSM, and business applications access the HSM through JCA / JCE or vendor-specific APIs for encryption and signing of large transactions; a government cloud platform uses domestically produced cryptographic machines to achieve encrypted storage and electronic signatures for e-government data; and large enterprise data centers deploy HSM clusters to provide key generation and certificate management services for multiple business systems.

[0006] While both methods have proven effective in their respective scenarios, they have revealed numerous security vulnerabilities and technical shortcomings in practical applications. In the direct integration of cryptographic libraries, keys are often stored in plaintext or weakly encrypted form in application server configuration files, database table fields, or environment variables, making them highly susceptible to unauthorized access or leakage. In scenarios such as large corporations, supply chain collaborations, and government data sharing, secure data sharing across security domains and organizational levels is required, but existing technologies lack effective key authorization and access control mechanisms.

[0007] Therefore, there is an urgent need for a unified cryptographic service solution that can ensure key security, support flexible sharing across levels, reduce development and maintenance costs, and provide high availability and disaster recovery capabilities. Summary of the Invention

[0008] In response to the high risk of key leakage caused by storing keys in plaintext or weak encryption on servers in existing technologies, this application provides a unified cryptographic service method and system that supports cross-level sharing. The root key never leaves the HSM hardware security module, the key encryption key (KEK) is generated and encrypted and stored inside the HSM, and the data encryption key (DEK) is only briefly decrypted in memory and then immediately erased. This layered key protection system fundamentally eliminates the risk of plaintext key storage and exposure.

[0009] One aspect of this application provides a unified cryptographic service method supporting cross-level sharing, comprising: S1, generating a root key within a Hardware Security Module (HSM) cluster; S2, generating a key encryption key (KEK) for encrypting other keys within the HSM cluster based on the root key, and encrypting the KEK using the root key before storing it in a distributed database; within the HSM cluster, generating a data encryption key (DEK) based on the KEK, encrypting the DEK using the KEK, and storing the encrypted DEK along with key metadata in a distributed database; wherein, the key metadata includes a key ID, creation time, associated KEK ID, and tenant identifier; S3, an API gateway receiving an encryption request sent by a business application and performing identity authentication and authorization; S4, after successful authentication in step S3, a cryptographic operation service instance calling a key management service (KMS); the KMS then retrieves the key from the distributed database based on the target key ID. The system retrieves the corresponding encrypted DEK and associated KEKID from the distributed database; decrypts the encrypted DEK using the KEK corresponding to the KEKID via HSM to obtain the plaintext DEK; KMS uses the plaintext DEK to encrypt the plaintext data to obtain ciphertext data and returns the ciphertext data to the business application; S5, the upper-level tenant grants access permissions for the target key to the corresponding lower-level tenant through the key sharing interface and records the sharing relationship in the key permission table; the sharing relationship includes the source tenant ID corresponding to the upper-level tenant, the target tenant ID corresponding to the lower-level tenant, the shared key ID, and the authorized operation type; when the lower-level tenant initiates a key usage request, KMS verifies whether the requester tenant ID is the owner of the target key or whether there is an authorized record in the key permission table. After verification, it performs key decryption and data encryption processing according to step S4 to achieve controlled sharing of keys between organizational levels.

[0010] The Hardware Security Module (HSM) refers to a dedicated cryptographic computing hardware device with tamper-proof physical characteristics, ensuring the security of key generation, storage, and cryptographic operations through hardware-level security mechanisms. In this application, a root key is generated within the HSM cluster and permanently resides within the HSM hardware security boundary, never being exported in plaintext, ensuring the highest level of security for the key system. A Key Encryption Key (KEK) is generated internally within the HSM based on the root key, and the KEK is encrypted using the root key before being stored in an external database, guaranteeing the confidentiality of the KEK. A Decryption Key (DEK) is generated and encrypted using the KEK internally, ensuring that the randomness and security of the DEK generation process comply with national cryptographic standards. During cryptographic operations, the HSM uses the KEK to decrypt the encrypted DEK stored in the database. The entire decryption process is completed within the HSM hardware security boundary; the plaintext KEK and DEK only exist briefly in the encrypted memory within the HSM.

[0011] Key Management Service (KMS) refers to a software service system that provides full lifecycle management of keys. It coordinates components such as HSM hardware, distributed databases, and access control to implement functions such as key creation, distribution, rotation, revocation, and auditing. In this application, KMS associates and stores the encrypted DEK with key metadata (key ID, creation time, associated KEK ID, tenant identifier, etc.) in a distributed database, establishing a key index and mapping relationship. It receives calls from cryptographic operation service instances and retrieves the corresponding encrypted DEK and associated KEK ID from the distributed database based on the target key ID.

[0012] A higher-level tenant refers to a tenant entity at a higher level in the organizational hierarchy that owns and allocates key resources. This typically corresponds to a group company, parent company, or business unit. The higher-level tenant creates and owns a specific data encryption key (DEK) through the KMS service, and is recorded as the original owner of the key in the key metadata. Based on business needs, the higher-level tenant proactively grants access permissions for target keys to lower-level tenants through the key sharing interface, determining which lower-level tenants can use which keys and the permitted operation types. In the key permission table's sharing relationship record, the higher-level tenant's ID is identified as the source tenant ID, indicating the initiator of the authorization relationship.

[0013] A lower-level tenant refers to a tenant entity at a lower level in the organizational hierarchy that obtains key usage rights through authorization from a higher-level tenant. These typically correspond to subsidiaries, branches, project teams, or business units. The lower-level tenant is not the owner of the target key; rather, it obtains limited usage rights to a specific key through proactive authorization from the higher-level tenant. When a lower-level tenant's business application needs to use the shared key, it initiates a key usage request to KMS, carrying the lower-level tenant's identity and the target key ID.

[0014] The source tenant is a field concept in the shared relationship record of the key permission table. It refers to the authorizing party in the key sharing authorization relationship, that is, the tenant entity that owns the key and actively shares the key usage rights with other tenants.

[0015] The target tenant is a field concept in the shared relationship record of the key permission table. It refers to the authorized recipient in the key sharing authorization relationship, that is, the tenant entity that obtains the key usage permission from the source tenant.

[0016] Furthermore, S2 generates a key encryption key (KEK) within the HSM cluster based on the root key, used to encrypt other keys. This includes: generating independent KEKs for different tenants, where a tenant represents an independent unit or business entity using a unified cryptographic service; encrypting the KEK corresponding to each tenant using the root key to obtain the encrypted KEK; associating the encrypted KEK with KEK metadata and storing it in a distributed database, where the KEK metadata includes KEKID, tenant ID, creation time, and key usage identifier; and establishing a mapping relationship between tenant ID and KEKID in the distributed database to achieve key isolation between different tenants.

[0017] Furthermore, in step S3, the API gateway receives an encrypted request sent by a business application, including: the API gateway receives the encrypted request sent by the business application via the HTTPS protocol. The encrypted request includes plaintext data, a target key ID, encryption algorithm parameters, and requester identity credentials, which may include an OAuth2 token or a JWT token; the requester identity credentials are verified to confirm the legitimacy of the business application, and the requester tenant ID is extracted after successful verification; the corresponding key metadata is queried from the distributed database based on the target key ID to obtain the tenant identifier associated with the target key ID; the requester tenant ID is verified to be consistent with the extracted tenant identifier, or the requester tenant ID is verified to have an authorization record for the target key ID in the key permission table established in step S5.

[0018] Among them, the OAuth2 token refers to the access credential generated and transmitted based on the OAuth 2.0 authorization framework protocol. It is used to prove to the resource server on behalf of the resource owner that the client application has been authorized to access protected resources or call specific APIs.

[0019] JWT tokens are a compact, self-contained token format based on the JSON-based open standard (RFC 7519) for securely transmitting claims between web applications. JWTs guarantee the integrity and authenticity of content through digital signatures or Message Authentication Codes (MACs), and optionally protect the confidentiality of content through encryption.

[0020] Furthermore, in step S5, the upper-level tenant grants access to the target key to the corresponding lower-level tenant through the key sharing interface. This includes: the upper-level tenant granting access to the target key to the lower-level tenant through the key sharing interface and submitting a sharing request, which includes the source tenant ID, target tenant ID, shared key ID, authorization operation type, and authorization validity period; verifying the legality of the sharing request: verifying whether the source tenant ID is the owner of the shared key ID, and whether the target tenant ID is a lower-level unit of the source tenant in the organizational hierarchy table; after successful verification, generating a first-level delegation key DKC1 containing the target DEK based on the KEK corresponding to the upper-level tenant; encrypting the first-level delegation key DKC1 with the lower-level tenant's public key to generate a second-level delegation key DKC2, and adding an access descriptor to DKC2; generating delegation keys from DKC1 to DKC2. The key chain and corresponding permission descriptors are stored in a distributed database. When a lower-level tenant's business application initiates a key usage request, it carries the access token issued by the upper-level tenant in the request. The KMS verifies the validity of the access token. After successful verification, it uses the delegated key chain index DKC1→DKC2 in the access token. It decrypts DKC2 using the lower-level tenant's private key to recover DKC1, and verifies the validity of DKC1 using the upper-level tenant's public key. It extracts the encrypted reference and permission scope of the target DEK from the verified DKC1. The KMS obtains the encrypted DEK based on the encrypted reference, decrypts it using the upper-level tenant's KEK through the HSM to obtain the plaintext DEK, and verifies whether the operation type of the current request is within the authorization scope defined by the permission descriptor. After successful permission verification, it uses the plaintext DEK to encrypt or decrypt the business data submitted by the lower-level tenant.

[0021] In a multi-tenant key management system, a delegated key chain is a chain-like data structure built hierarchically by upper-level tenants (key owners) and lower-level tenants (authorized parties) to securely delegate and transfer key access permissions. This chain structure ensures that only authorized tenants can access the target key within their authorized scope through layer-by-layer encryption and signing, while also guaranteeing the confidentiality and integrity of the key materials during transmission.

[0022] The DKC1→DKC2 index refers to a metadata indexing mechanism in the distributed database of the key management system used to quickly locate and retrieve the delegated key chain path between specific tenants. This index enables efficient lookup and association from DKC1 to DKC2 through the chain identifier (chain_id) carried in the access token or query parameters (such as the target tenant ID or shared key ID), supporting the real-time verification and decryption process of key usage requests.

[0023] Furthermore, the process of generating the delegated key chain from DKC1 to DKC2 and the corresponding permission descriptors includes: generating a first-level delegated key DKC1 based on the KEK corresponding to the upper-level tenant; the data structure of DKC1 includes the storage location index of the target DEK in the distributed database, the DEK fragment in ciphertext form, and the defined permission range for the data access categories; digitally signing DKC1 using the private key pre-generated and stored by the upper-level tenant in the HSM cluster; obtaining the public key of the lower-level tenant and using the public key to perform asymmetric encryption on DKC1 to generate the second-level delegated key DKC2; embedding permission descriptors in the data structure of DKC2; the permission descriptors are defined in JSON or XML format, including the types of operations that the recipient can perform, the identifier of the data range allowed to be accessed, the maximum number of accesses threshold, and the upper limit of the amount of data accessed in a single access; and storing the delegated key chain from DKC1 to DKC2 and the corresponding permission descriptors to establish a mapping relationship from the shared key ID of the upper-level tenant to the access permissions of the lower-level tenant.

[0024] Furthermore, the permission descriptor is defined in JSON format and includes the following fields: a list of authorized operation types (allowedOperations), with values ​​of encrypt, decrypt, sign, or verify; a data scope identifier (dataScope), defining the accessible data category or data set; a maximum access count threshold (maxAccessCount), limiting the maximum number of times the delegated keychain can be used; a single access data size limit (maxDataSize), limiting the data size of a single encryption or decryption operation in bytes; and an access time window (timeWindow), including a start time (startTime) and an end time (endTime). When a lower-level tenant initiates a key usage request using the delegated keychain, KMS extracts the permission descriptor from DKC2 and verifies each item to ensure that the current request complies with the permission constraints.

[0025] Furthermore, S1, the root key is generated within the hardware security module HSM cluster, including: adopting a triple TMR architecture in the HSM cluster, with each HSM module independently generating root key fragments; dividing the root key into N fragments using the Shamir secret sharing algorithm, setting a threshold M, where M is less than or equal to N, and M and N are positive integers, and any M fragments can recover the root key; each HSM module performs local encrypted storage of the root key fragments, and the root key is only used for reassembly within the HSM; only the root key's metadata is recorded in the distributed database, where the root key's metadata includes the root key ID, creation timestamp, the HSM cluster to which it belongs, and the key status identifier; establishing a root key rotation strategy, generating a new version of the root key according to a preset period, and the old version of the root key only supports the decryption of historical data.

[0026] The TMR architecture (Triple Module Redundancy) is a fault-tolerant architecture based on redundancy design. It deploys three functionally identical but physically independent hardware modules that execute the same task in parallel, and uses a majority voting mechanism to compare the outputs of the three modules, thereby achieving automatic detection, isolation, and fault-tolerant recovery from single points of failure. In step S1 of this scheme, the TMR architecture is applied to the HSM (Hardware Security Module) cluster to ensure high availability, high reliability, and resistance to physical attacks in the root key generation and management process.

[0027] Furthermore, it also includes: S6, setting a key rotation mechanism: The KMS service scans the DEK metadata marked as automatically rotated in the distributed database at a preset period, and performs rotation operations according to preset trigger conditions, including time-driven triggering and usage-driven triggering; time-driven triggering is executed according to a preset rotation period, which may be once a day, once a week, or once a month; usage-driven triggering is executed when the number of times a DEK is used exceeds a preset threshold; when performing rotation, KMS generates a new version of DEK within the HSM cluster, encrypts the newly generated DEK using the current KEK, stores the encrypted DEK in the distributed database, and updates the version number and creation time in the key metadata; the old version of DEK is marked as decryption-only, and is only used to decrypt historical data.

[0028] Furthermore, this includes: S7, setting up a multi-tenant resource isolation mechanism: At the network layer, a Calico network strategy is adopted, configuring an independent network namespace for each tenant to restrict network communication between different tenant Pods, allowing only controlled access through the API gateway; at the storage layer, a schema isolation mode is adopted, creating an independent database schema or tablespace for each tenant in the distributed database. The database schema contains the corresponding tenant's key metadata table, audit log table, and permission configuration table; at the compute resource layer, the Kubernetes ResourceQuota mechanism is adopted, setting CPU quotas, memory quotas, and storage quota limits for each tenant; at the HSM resource layer, independent key partitions or key slots are allocated to different tenants, ensuring physical key isolation between tenants through access control lists (ACLs) within the HSM; at the audit layer, an independent audit log stream is generated for each tenant, using different log storage paths and access permissions, so that tenants can only query their own operation audit records.

[0029] Calico network policy is a Kubernetes native network policy enhancement mechanism implemented based on the Calico open-source network solution. It defines fine-grained access control rules at the network layer (layers 3 and 4 of the OSI model) to achieve Pod-level network traffic management, tenant network isolation, and micro-segmentation in containerized environments.

[0030] Schema isolation is a logical isolation strategy in multi-tenant database architectures. It achieves logical separation and access control of tenant data by creating an independent database schema or tablespace for each tenant within the same database instance. Schema isolation is applied to distributed databases (such as PostgreSQL, TiDB, and CockroachDB), creating an independent schema for each tenant to store key metadata tables, audit log tables, and permission configuration tables. This ensures data isolation between tenants, independence in query performance, and compliance with data sovereignty and compliance requirements.

[0031] Preferably, it also includes: S8, setting an emergency collaborative fault switching mechanism: the fault detection and arbitration center monitors the health status of the HSM cluster, KMS service instance, and distributed database of the primary data center in real time through the gRPC-Health protocol, with a monitoring frequency of once per second; when fault symptoms are detected in the primary data center, including service response timeout, health check failure rate exceeding the threshold, or network partition event, the fault detection and arbitration center triggers the fault arbitration process; the arbitration process adopts a distributed decision-making mechanism based on the Raft consensus protocol, with multiple geographically distributed arbitration nodes voting to decide whether to perform primary / backup switching, and switching is triggered when more than half of the arbitration nodes confirm the fault; the service scheduler notifies the HSM cluster and KMS service of the backup data center to enter the active state, and obtains the logical ID and physical location mapping relationship of all keys through the global key directory service; wherein, the global key directory service is implemented using a distributed key-value storage system, and the distributed key... The value storage system, based on the Raft consensus protocol, ensures strong consistency and is deployed across at least three geographically dispersed data centers. It maintains a directory entry for each key, with the key's logical ID as the key and the value containing the key's physical storage location, its HSM cluster identifier, primary / standby status flag, last update timestamp, and synchronization status flag. When a key in the primary data center changes (e.g., adding a key, key rotation, or key destruction), the change event is asynchronously pushed to the global key directory service via a message queue, updating the corresponding directory entry. The KMS service in the standby data center periodically synchronizes the key directory from the global key directory service every 5 minutes to ensure the standby system has the latest key distribution information. During failover, the service scheduler queries the global key directory service to obtain the current valid location of all keys and routes key operation requests to the corresponding HSM cluster based on the location information, avoiding key addressing failures due to primary / standby failover.

[0032] The backup HSM cluster restores its service capabilities from the root key metadata synchronized from the primary HSM cluster through a secure channel. The secure channel adopts a two-way authentication encrypted tunnel based on TLS 1.3. The API gateway updates its routing configuration to route all new business requests to the backup data center. Business applications continue to use the original key ID to access the service, achieving seamless business switching. The RTO recovery time of the entire switching process is controlled within 30 seconds.

[0033] Another aspect of this application provides a unified cryptographic service system that supports cross-level sharing, for implementing a unified cryptographic service method that supports cross-level sharing according to this application.

[0034] Compared to existing technologies, the advantages of this application are:

[0035] This application establishes a three-layer key protection system:

[0036] First, the root key is generated and permanently resides within the HSM cluster using the Shamir secret-sharing algorithm, never physically leaving the HSM security boundary. Even if the HSM device is physically stolen, the root key cannot be cracked or extracted, eliminating the possibility of core key leakage at the source. The key encryption key (KEK) is generated internally within the HSM and protected by encryption using the root key. The encrypted KEK is stored in a distributed database. Even if an attacker gains database access, they can only obtain the ciphertext KEK and cannot decrypt it. Compared to existing technologies that store keys in plaintext or with weak encryption in configuration files, this represents a security improvement of several orders of magnitude.

[0037] Secondly, when the data encryption key DEK is used, it is only briefly decrypted in the encrypted memory area of ​​the cryptographic operation service instance (by default, no more than 60 seconds). After the encryption or decryption operation is completed, the memory is immediately cleared through a secure erase function, which avoids the risk that the key may be dumped or obtained by side-channel attacks if it resides in memory for a long time in the existing technology.

[0038] Finally, through the delegated key chain mechanism and permission descriptors, minimum permission sharing across organizational levels is achieved. Upper-level tenants can precisely limit the operation types (encryption / decryption / signature / verification), data range, access limit, single data volume limit, and effective time window for lower-level tenants, and record complete audit logs through the blockchain evidence storage system, completely solving the problems of uncontrolled permissions and difficulty in audit traceability caused by the direct plaintext transmission of keys in existing technologies. Attached Figure Description

[0039] This application will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:

[0040] Figure 1 This is an overall architecture diagram of a unified cryptographic service platform shown according to some embodiments of this application;

[0041] Figure 2 This is a schematic diagram of a key hierarchical management and delegated key chain mechanism according to some embodiments of this application;

[0042] Figure 3 This is a timing diagram of a cross-level data decryption process according to some embodiments of this application. Detailed Implementation

[0043] The methods and systems provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0044] Example 1

[0045] This platform adopts a layered, microservice architecture, mainly including an access layer, a service layer, and a core infrastructure layer, and adds a cross-layer sharing module and an emergency collaboration module.

[0046] Access layer:

[0047] API Gateway: Provides a unified RESTful / gRPC API entry point. It is responsible for request routing, authentication (OAuth2 / JWT), authorization, SSL / TLS termination, rate limiting, circuit breaking, and logging.

[0048] Management console: WebUI, used for key management, service monitoring, alarm configuration, user / role / permission management, audit log query, cross-domain sharing policy configuration, and emergency drill management.

[0049] Multi-language SDK: Provides SDKs for Java, Go, Python, Node.js, etc., encapsulates API call details, and simplifies client integration.

[0050] Service layer (microservice cluster):

[0051] Key Management Service (KMS): The core engine. Responsible for the entire lifecycle management of keys, including the generation, storage, rotation, and destruction of root keys, KEKs, and DEKs.

[0052] Root key management: Generated and permanently resides only within the HSM cluster.

[0053] KEK Management: Encrypted by the root key and stored in a distributed, highly available database.

[0054] DEK management: It is protected by the corresponding KEK encryption, stored in encrypted form, and decrypted in memory when used.

[0055] Cryptographic computation service: includes stateless microservice instances that provide atomic services such as encryption / decryption, signing / verification, and hashing.

[0056] Cross-level shared modules:

[0057] Delegated Key Chain Generator: The initiator calls this interface to generate a hierarchical delegated key chain.

[0058] Permission verifier: When the receiver requests decryption, it verifies whether the delegated key it holds has permission to access the target DEK.

[0059] Dynamic token issuer: issues time-limited access tokens for shared sessions.

[0060] Emergency Collaboration Module:

[0061] Fault Detection and Arbitration Center: Monitors the health status of each cluster in real time and triggers a switchover process when a fault occurs.

[0062] Global Key Directory Service: Maintains the mapping between the logical ID of all keys and their physical location (HSM cluster, data center).

[0063] Service scheduler: Routes requests to available backup clusters based on failure conditions and policies.

[0064] Certificate Services: (Optional) Manage and interact with the CA, providing certificate issuance, revocation inquiry, and verification services.

[0065] Core infrastructure layer:

[0066] HSM Cluster: Provides a hardware security environment compliant with FIPS standards. All root keys and KEKs are generated and permanently reside here. Cluster deployment guarantees high availability.

[0067] Distributed high-availability database: Stores key metadata, access policies, audit logs, service configurations, global key directory, etc. The data itself is stored encrypted. Clustering ensures persistence and availability.

[0068] Service registration and discovery (such as Consul, Eureka, Nacos) is used for the dynamic management of instances of cryptographic computing services, cross-level shared modules, and emergency collaboration modules.

[0069] Message queues (such as Kafka and RabbitMQ) are used for asynchronous processing of key rotation notifications, audit log collection, cross-domain event sharing, etc.

[0070] Secure Channel: A secure channel for synchronizing root key metadata between primary and backup HSM clusters.

[0071] Data encryption process: The business application calls the cryptographic service API ` / encrypt`, passing in the plaintext data, target key ID, and algorithm. The API gateway performs authentication and authorization, routing the request to the encryption service instance. The encryption service instance calls the KMS service's GetEncryptedDEK interface. The KMS service retrieves the encrypted DEK (EDK) from the database based on the key ID. If the DEK does not exist or needs to be generated, it generates the DEK in the HSM, encrypts it with the corresponding KEK to obtain the EDK, stores it in the database, and returns it. The encryption service instance decrypts the EDK in memory to obtain the DEK, uses the DEK to encrypt the plaintext data, and returns the ciphertext.

[0072] Cross-level data decryption process (lower-level unit decrypts higher-level data): The lower-level unit's business system requests decryption of encrypted data from the higher-level unit, carrying a temporary access token issued by the higher-level unit. The cross-level shared module's permission verifier verifies the token's validity and access permissions. The KMS service obtains the EDK of the target DEK (which may be stored in the higher-level unit's HSM or a location pointed to by the global directory). The local KMS uses its own authorized KEK to decrypt the EDK to obtain the DEK (or obtains the decrypted DEK remotely from the group's HSM, depending on the sharing policy). The DEK is then used to decrypt the business data.

[0073] Primary platform failure emergency switchover process: The unified resource service center detects a failure in the primary data center cluster. It notifies the backup cluster to initiate the emergency collaboration process. The backup cluster obtains the logical IDs and statuses of all keys through the global key directory. The backup cluster obtains the necessary root key information (not the root key itself) from the remote HSM (metadata synchronized via a secure channel) and initializes the service. The API gateway routes business requests to the backup cluster, and the business systems continue to access services using the original key IDs without being aware of the failure.

[0074] Key hierarchical management and cross-domain sharing implementation: Root Key: Exists only within the HSM and never leaves. KEK: Encrypted by the root key and stored in an external database, supporting isolation by business unit / tenant. DEK: Encrypts business data; ciphertext and data coexist, and decryption occurs in memory during use. Delegated Key Chain: Generated by the initiator, restricting the recipient to decrypting only specific DEKs, and has an expiration time. Global Key Directory: Maintains the mapping from logical key IDs to physical locations, supporting multi-active scheduling.

[0075] In summary, in this application, (1) the root key and KEK never leave the HSM, and the DEK is minimized, fundamentally eliminating the risk of core key leakage. Key rotation, access control, and audit logs are fully automated, easily meeting the requirements of regulations such as the Information Security Protection 2.0, GDPR, and PCIDSS. The delegated key chain and dynamic token mechanism realize the least privilege sharing across security domains, and the audit trace is clear. (2) Business systems obtain powerful cryptographic capabilities through simple API / SDK calls, without the need for cryptographic expertise. Centralized key management, monitoring, and auditing significantly reduce the operational burden and manpower costs. Stateless services can be infinitely horizontally scaled, easily coping with traffic peaks. (3) The HSM cluster provides accelerated cryptographic operations, and stateless services guarantee concurrent processing capabilities. Clustered deployment eliminates single points of failure, and services switch in seconds. The emergency collaboration module ensures that the master-slave switch RTO is less than 30 seconds, and business continuity is not affected. The off-site cold standby cluster is immune to local disasters and ransomware.

[0076] Example 2

[0077] like Figure 1The diagram shows the overall architecture of the unified cryptographic service platform described in this invention. The access layer includes an API gateway serving as the unified entry point, a management console providing visual management, and an SDK supporting multi-language integration. The service layer includes a KMS service that directly connects to the HSM cluster (hardware security module) and a distributed database (storing key metadata). A cryptographic computation service interacts with other components in the service layer through cross-layer sharing modules and emergency collaboration modules. The infrastructure layer includes a secure channel that ensures the security of root key metadata synchronization between primary and backup HSM clusters. Global interaction involves all components collaborating through service registration and discovery (e.g., Consul) and message queues (e.g., Kafka).

[0078] Specifically, the access layer, serving as the system's external interface, comprises three core components: API Gateway: Receives cryptographic service requests (such as encryption, decryption, signing, and signature verification) from business applications. After authentication, permission verification, and traffic control, it forwards legitimate requests to the cryptographic computation service module in the service layer for processing. Management Console: Provides a visual management interface for system administrators and tenant administrators, used for tenant creation, key lifecycle management, permission configuration, audit log querying, and other operations. Management commands are distributed to various functional modules in the service layer through a secure channel. Multi-language SDK: Encapsulates standardized cryptographic service call interfaces, supporting mainstream development languages ​​such as Java, Python, Go, and C++. Business applications can easily call cryptographic services by integrating the SDK without needing to concern themselves with the underlying implementation details.

[0079] The service layer is the core business logic processing layer of the system, responsible for cryptographic operations, key management, and data storage. It includes the following modules and data processing flow:

[0080] Cryptographic Operation Service: Upon receiving a cryptographic operation request forwarded by the API gateway, it first requests the necessary data encryption key (DEK) metadata (including the encrypted DEK ciphertext, associated KEK identifier, etc.) from the key management module. After obtaining the metadata, it sends the encrypted DEK to the HSM cluster for decryption via a secure channel. The HSM uses the corresponding KEK to decrypt the DEK and returns the plaintext DEK. The cryptographic operation service receives the plaintext DEK in the encrypted memory area. After completing the data encryption or decryption operation, it immediately erases the plaintext DEK from memory and returns the operation result to the API gateway.

[0081] Cross-tier sharing module: Handles key authorization and delegated access requests between tenants. When an upper-level tenant shares a key with a lower-level tenant, this module creates a delegated key chain record, writes the permission descriptor (including allowed operation types, data ranges, validity periods, etc.) to the distributed database, and asynchronously notifies the relevant tenants via a message queue. When a lower-level tenant uses the delegated key to perform data operations, the module verifies the validity of the permission descriptor and records the operation log to the audit system.

[0082] Emergency Negotiation Module: This module automatically triggers a failover mechanism when an HSM cluster or distributed database fails. It interacts with the service registration and discovery components at the infrastructure layer to monitor the health status of each storage node in real time. When the primary node fails, the module selects an available node from the standby node list, updates data access routes, and ensures uninterrupted reading of key metadata. During the failover process, metadata requests are automatically redirected to the standby distributed database node.

[0083] Key Management Module: Responsible for the entire lifecycle management of keys. When creating a new key, this module generates key metadata (including key ID, algorithm type, creation time, associated tenant, etc.) and sends a KEK generation request to the HSM cluster via a secure channel. HSM encrypts the newly generated KEK using the root key and returns the ciphertext. The Key Management Module stores the encrypted KEK and metadata in a distributed database. During key rotation, the module generates a new version of the KEK, re-encrypts all associated DEKs using the new KEK, and updates the version mapping relationship in the database. When a key is destroyed, the module sends a key deletion command to HSM, logically deletes the corresponding record from the database, and writes the operation log to the audit system.

[0084] The HSM cluster, acting as the system's root of trust, is responsible for the generation, storage, and protection of the root key, as well as the generation, encryption, and decryption of the KEK and DEK. The HSM employs a master-slave hot standby architecture, with the master node handling cryptographic computation requests and slave nodes synchronizing their status in real time. The root key is sharded and stored across multiple HSM nodes using the Shamir secret sharing algorithm, ensuring that the complete root key cannot be reconstructed if any single node is compromised. The HSM communicates with the cryptographic computation service and key management module via a bidirectional TLS encrypted channel, ensuring the secure transmission of key materials.

[0085] Distributed database: Employing a multi-replica strong consistency architecture, it stores encrypted KEK and DEK metadata, tenant information, permission descriptors, delegated key chains, and other critical data. During data writes, the master node synchronizes and replicates changes to at least two slave nodes before returning a success confirmation, ensuring no data loss. An emergency negotiation module dynamically adjusts read / write routes by reading health check records from the database, enabling automatic failover in case of failure. The database periodically backs up metadata snapshots to object storage for disaster recovery.

[0086] The infrastructure layer provides underlying technical support for the service layer:

[0087] Service Registration and Discovery: Distributed coordination services such as etcd or Consul are used to maintain the registration information and health status of the HSM cluster, distributed database nodes, and cryptographic computation service instances. Each service module reports its address and status to the registry center upon startup and sends heartbeats periodically. The emergency negotiation module subscribes to change events in the registry center and triggers failover logic when a node failure is detected.

[0088] Message Queues: Asynchronous message passing is implemented using Kafka or RabbitMQ to decouple synchronous dependencies between service modules. For example, after the key management module creates a new key, it notifies the cross-level sharing module to update the permission cache via a message queue; after the cryptographic operation service completes its operation, it asynchronously sends audit logs to the log collection system via a message queue to avoid synchronous writing affecting the performance of the main process.

[0089] Secure Channel: Based on the TLS 1.3 protocol, a two-way authenticated encrypted channel is established between the service layer module and the HSM cluster and distributed database. The channel uses the Chinese national cryptographic algorithm SM2 / SM4 or the international standard AES-256-GCM algorithm for data encryption and digital certificates for authentication. Key materials transmitted within the secure channel (such as encrypted KEK and DEK ciphertext) cannot be decrypted even if intercepted.

[0090] like Figure 2 The diagram illustrates a hierarchical key management and delegated key chain mechanism. The root key is generated internally within the HSM and never leaves the system. Key chain protection: The root key encrypts and protects the KEK, which in turn encrypts and protects the DEK. During cross-domain sharing, the initiator generates a delegated key chain (DKC1→DKC2), authorizing only the recipient to decrypt a specific DEK.

[0091] like Figure 3 As shown, token verification ensures recipient permissions. The global key directory locates the DEK storage location. The DEK is obtained remotely from the group's HSM via a secure channel to prevent root key leakage.

[0092] Specifically, when a subsidiary's business system needs to decrypt business data encrypted by the parent company, it sends a decryption request to the cross-level shared module, carrying an access token. This token is obtained by the subsidiary from the global key directory during system initialization and contains the subsidiary's tenant identifier, access credentials, and signature information.

[0093] Upon receiving a decryption request, the cross-level sharing module forwards the token to the authorization verifier for verification. The authorization verifier performs the following checks: verifies the validity of the token signature and confirms that the request originates from a registered subsidiary tenant; checks whether the token is valid, has not been revoked, or has expired; and extracts the subsidiary tenant ID and the requested data encryption key (DEK) identifier from the token.

[0094] After completing the verification, the permission verifier returns the verification result to the cross-level sharing module, including: whether the verification passed (pass / reject); the permission descriptor of the subsidiary tenant, which includes the allowed operation type (decryption in this scenario), data range, validity period, access limit and other constraints; and the delegated key chain information, which identifies the DEK authorized by the parent company for use by the subsidiary and the associated key encryption key KEK.

[0095] The cross-level sharing module queries the KMS service for the encrypted form of the DEK (EncryptedDEK, or EDK for short) based on the DEK identifier in the permission descriptor. The query request includes: the globally unique identifier of the DEK; the subsidiary tenant ID, used to verify access permissions; and the delegated key chain ID, proving that the DEK has been authorized for sharing by the parent company.

[0096] After receiving a query request, the KMS service performs the following operations: retrieves DEK metadata from the distributed database, including the encrypted DEK ciphertext (EDK), the associated KEK identifier, key version, creation time, and other information; verifies the validity of the delegated key chain to confirm that the parent company has indeed authorized the subsidiary to access the DEK; and queries the key sharding mapping table to determine the physical address of the HSM cluster where the KEK that encrypted the DEK resides (in this scenario, the group's HSM).

[0097] The KMS service returns query results to the cross-level shared module, including: the encrypted DEK ciphertext (EDK); the HSM cluster address (network endpoint of the group HSM) responsible for decrypting the DEK; the KEK identifier, used by the HSM to locate the correct key encryption key; and the audit trace ID of this operation, used for subsequent log association.

[0098] The cross-level shared module sends a decryption request to the group's HSM through a secure channel (TLS 1.3 two-way certified encrypted connection). The request parameters include: the encrypted DEK ciphertext (EDK); the KEK identifier; the requesting tenant ID (subsidiary) and the delegated key chain ID, which are used for access control verification on the HSM side; and the operation type identifier (decryption operation).

[0099] Upon receiving a decryption request, the Group's HSM performs the following operations within the hardware security boundary: Based on the KEK identifier, it loads the corresponding key encryption key KEK from the HSM's internal key storage area (the KEK itself is encrypted and protected by the root key); it decrypts the KEK using the root key to obtain the plaintext KEK (this process is completed internally within the HSM chip, and the plaintext KEK never leaves the HSM); it decrypts the EDK using the plaintext KEK to obtain the plaintext DEK; it verifies the delegated key chain permissions, confirming that the subsidiary tenant has the authority to use the DEK for decryption operations; and it returns the plaintext DEK to the cross-level shared module via an encrypted channel.

[0100] The Group's HSM returns the decrypted plaintext DEK to the cross-level shared module via a secure channel. During transmission, the DEK is protected by secondary encryption using a TLS session key to prevent interception during network transmission. The cross-level shared module receives the plaintext DEK in the encrypted memory area and records this key access operation to the global key directory, including: access timestamp, requester (subsidiary tenant ID), access key (DEK identifier), operation type (decryption), and data volume or access count.

[0101] The cross-level sharing module transmits the plaintext DEK to the subsidiary's local KMS system through a secure channel. During the transmission: the DEK is encapsulated and encrypted using the public key of the subsidiary's local KMS to ensure that only the subsidiary's local KMS can decrypt it; an access descriptor copy is attached to limit the scope of use and validity period of the DEK; and the delivery record is written to the blockchain notarization system to ensure that the key transfer process is tamper-proof and traceable.

[0102] After receiving the encrypted DEK from the subsidiary's local KMS: it uses its own private key to decrypt the DEK and obtain the encryption key for the plaintext data; it briefly loads the plaintext DEK into encrypted memory (by default, no more than 60 seconds); it uses the DEK to decrypt the encrypted business data submitted by the subsidiary's business system; after decryption, it immediately calls the secure erase function to clear the plaintext DEK in memory to prevent memory dump attacks; and it returns the decrypted plaintext business data to the subsidiary's business system through a secure channel.

[0103] The subsidiary's business system receives the decrypted plaintext data and completes the business logic processing. Throughout the process: the plaintext DEK exists only in the encrypted memory of the subsidiary's local KMS for no more than 60 seconds; the key decryption operation is completed within the group's HSM hardware security boundary, and the plaintext KEK and root key never leave the HSM; all key access and data operations are recorded in the global key directory and blockchain evidence storage system, forming a complete audit chain.

[0104] Switching Guarantee: Second-level switching: Relies on strong consistency of the global key directory (Raft protocol). Seamless Experience: Business systems access using the same key ID, ensuring a seamless transition.

[0105] Specifically, the API interface design includes request parameters, response formats, and error codes for core APIs such as / v1 / keys (key management), / v1 / encrypt, / v1 / decrypt, / v1 / sign, / v1 / verify, / v1 / share / delegate (delegation), and / v1 / share / revoke (revoke delegation).

[0106] Service discovery and load balancing: When the cryptographic computation service instance starts, it registers metadata (IP, port, health status) with Consul. The API gateway monitors service health in real time via the gRPC-Health protocol.

[0107] Load balancing strategies: Encryption / decryption requests: routed to a fixed instance based on consistent hashing (ensuring DEK cache hit rate). KMS requests: distributed in round-robin fashion (stateless operation).

[0108] Key rotation policy configuration and execution:

[0109] Automated rotation process:

[0110] Triggering conditions: Time-driven: All keys marked AUTO_ROTATE are automatically rotated daily at 00:00. Usage-driven: Triggered when the number of times the DEK is used exceeds a threshold (e.g., 100,000 times).

[0111] KMS generates a new DEK in HSM → encrypts the new DEK with the old KEK → updates the database. Businesses are unaware of this: the old DEK can still be used to decrypt historical data, but new data is forced to use the new DEK.

[0112] Multi-tenant isolation: A three-layer isolation mechanism is established. The network layer uses the Calico network policy to restrict cross-tenant Pod communication; the storage layer is partitioned by tenant ID (SchemaIsolation); and the resource layer adopts the Kubernetes ResourceQuota architecture.

[0113] Strong consistency is achieved by employing an availability zone deployment architecture, an Active-Active or Active-Standby mode for HSM clusters, master-slave replication and read-write separation for the database, and the Raft consensus protocol for a global key directory.

[0114] Configure cross-level sharing policies:

[0115] The HSM cluster employs a triple redundancy (TMR) architecture, ensuring service continuity even in the event of a single chip failure. The root key is never exported, making it unbreakable even if the HSM is physically stolen.

[0116] Emergency Collaboration Reliability: Chaos Engineering Testing: Monthly simulations of scenarios such as data center fires and fiber optic cable cuts verify a switchover success rate of ≥99.99%. Rollback Mechanism: If data inconsistency is found after a switchover, the system automatically rolls back to the original cluster.

[0117] Audit compliance: All operation logs are written to a blockchain-based evidence storage system to prevent tampering. An audit report template compliant with ISO 27001 is provided.

[0118] The foregoing illustrative description of the present application and its embodiments is not restrictive and can be implemented in other specific forms without departing from the spirit or essential characteristics of the present application. The accompanying drawings are only one embodiment of the present application, and the actual structure is not limited thereto. Therefore, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the present application, such designs should fall within the scope of protection of this application. Furthermore, the word "comprising" does not exclude other elements or steps, and the word "a" preceding an element does not exclude the inclusion of "a plurality" of that element. Terms such as "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A unified cryptographic service method supporting cross-level sharing, characterized in that, include: S1 generates the root key within the hardware security module HSM cluster; S2, based on the root key, generates a key encryption key KEK inside the HSM cluster to encrypt other keys, and then encrypts KEK using the root key and stores it in the distributed database. Within the HSM cluster, a data encryption key DEK is generated based on KEK, and the DEK is encrypted using KEK. The encrypted DEK is then associated with key metadata and stored in a distributed database. The key metadata includes key ID, creation time, associated KEKID, and tenant identifier. S3, the API gateway receives encrypted requests sent by business applications and performs identity authentication and permission authorization. S4. After authentication is successful in step S3, the cryptographic operation service instance calls the key management service KMS. KMS retrieves the corresponding encrypted DEK and associated KEKID from the distributed database based on the target key ID; The encrypted DEK is decrypted using the KEK corresponding to the KEKID via HSM to obtain the plaintext DEK; KMS uses plaintext DEK to encrypt plaintext data to obtain ciphertext data, and then returns the ciphertext data to the business application. S5, the upper-level tenant grants access to the target key to the corresponding lower-level tenant through the key sharing interface, and records the sharing relationship in the key permission table; wherein, the sharing relationship includes the source tenant ID corresponding to the upper-level tenant, the target tenant ID corresponding to the lower-level tenant, the shared key ID, and the authorization operation type; When a lower-level tenant initiates a key usage request, KMS verifies whether the requester's tenant ID is the owner of the target key or whether there is an authorized record in the key permission table. After successful verification, the key is decrypted and the data is encrypted in step S4 to achieve controlled sharing of the key between organizational levels.

2. The unified cryptographic service method supporting cross-level sharing according to claim 1, characterized in that: S2, based on the root key, generates a key encryption key (KEK) within the HSM cluster for encrypting other keys, including: Generate independent KEKs for different tenants, where a tenant represents an independent unit or business entity using a unified cryptographic service; The root key is used to encrypt the KEK corresponding to each tenant, resulting in the encrypted KEK; The encrypted KEK is associated with and stored in a distributed database. The KEK metadata includes KEKID, tenant ID, creation time, and key usage identifier. Establish a mapping relationship between tenant ID and KEKID in the distributed database to achieve key isolation between different tenants.

3. The unified cryptographic service method supporting cross-level sharing according to claim 1, characterized in that: S3, the API gateway receives encrypted requests from business applications and performs identity authentication and authorization, including: The API gateway receives encrypted requests from business applications via the HTTPS protocol. The encrypted request includes plaintext data, target key ID, encryption algorithm parameters, and requester identity credentials, which may include an OAuth2 token or a JWT token. Verify the requester's identity credentials to confirm the legitimacy of the business application. Once the verification is successful, extract the requester's tenant ID. Based on the target key ID, query the corresponding key metadata stored in the distributed database to obtain the tenant identifier associated with the target key ID; Verify whether the requester's tenant ID matches the extracted tenant identifier, or verify whether the requester's tenant ID has an authorization record for the target key ID in the key permission table established in step S5.

4. The unified cryptographic service method supporting cross-level sharing according to claim 2 or 3, characterized in that: S5, the upper-level tenant grants access to the target key to the corresponding lower-level tenant through the key sharing interface, including: The upper-level tenant grants access to the target key to the lower-level tenant through the key sharing interface and submits a sharing request. The sharing request includes the source tenant ID, target tenant ID, shared key ID, authorization operation type, and authorization validity period. Verify the legitimacy of the sharing request: Verify whether the source tenant ID is the owner of the shared key ID, and whether the target tenant ID is a subordinate unit of the source tenant in the organization hierarchy table; After successful verification, a first-level delegation key DKC1 containing the target DEK is generated based on the KEK corresponding to the upper-level tenant. The first-level delegation key DKC1 is encrypted with the public key of the lower-level tenant to generate the second-level delegation key DKC2, and a permission descriptor is added to DKC2. Generate delegated key chains from DKC1 to DKC2 and their corresponding permission descriptors, and store them in a distributed database; When a lower-level tenant's business application initiates a key usage request, it carries the access token issued by the upper-level tenant in the request; KMS verifies the validity of the access token. After the token is verified, it proceeds according to the delegated key chain index DKC1→DKC2 in the access token. Use the private key of the lower-level tenant to decrypt DKC2 and recover DKC1, and use the public key of the upper-level tenant to verify the validity of DKC1. Extract the encrypted reference and permission scope of the target DEK from the verified DKC1. KMS obtains the encrypted DEK based on the encrypted reference, decrypts it using the KEK of the upper-level tenant through HSM to obtain the plaintext DEK, and verifies whether the operation type of the current request is within the authorization scope defined by the permission descriptor. After successful authorization verification, the plaintext DEK is used to encrypt or decrypt the business data submitted by the lower-level tenant.

5. The unified cryptographic service method supporting cross-level sharing according to claim 4, characterized in that: Generate delegated key chains from DKC1 to DKC2 and their corresponding permission descriptors, including: The first-level delegation key DKC1 is generated based on the KEK corresponding to the upper-level tenant. The data structure of DKC1 includes the storage location index of the target DEK in the distributed database, the DEK fragment in ciphertext form, and the defined access permission scope of the data category. Use the private key that the upstream tenant has pre-generated and stored in the HSM cluster to digitally sign DKC1; Obtain the public key of the lower-level tenant, use the public key to perform asymmetric encryption on DKC1, and generate the second-level delegation key DKC2; Embed permission descriptors in the DKC2 data structure. The permission descriptors are defined in JSON or XML format, including the types of operations that the receiver can perform, the identifier of the range of data that can be accessed, the maximum number of accesses threshold, and the upper limit of the amount of data accessed in a single session. Store the delegated key chains from DKC1 to DKC2, and the corresponding permission descriptors, to establish a mapping relationship from the shared key ID of the upper-level tenant to the access permissions of the lower-level tenant.

6. The unified cryptographic service method supporting cross-level sharing according to claim 5, characterized in that: The permission descriptor is defined in JSON format and contains the following fields: a list of authorized operation types: allowedOperations; Data scope identifier: dataScope; maximum access count threshold: maxAccessCount; maximum data size per access: maxDataSize; Access the time window (timeWindow); When a lower-level tenant initiates a key usage request using the delegated key chain, KMS extracts the permission descriptor from DKC2 and verifies each item to determine whether the current request complies with the permission constraints.

7. The unified cryptographic service method supporting cross-level sharing according to claim 5 or 6, characterized in that: S1 generates a root key within the HSM hardware security module cluster, including: The HSM cluster adopts a triple TMR architecture, with each HSM module independently generating root key fragments; The root key is divided into N pieces using the Shamir secret sharing algorithm. A threshold M is set, where M is less than or equal to N, and M and N are positive integers. Any M pieces can be used to recover the root key. Each HSM module performs local encrypted storage of root key fragments, and the root key is only used for reassembly within the HSM. Only the metadata of the root key is recorded in the distributed database. The metadata of the root key includes the root key ID, creation timestamp, the HSM cluster to which it belongs, and the key status identifier. Establish a root key rotation strategy to generate a new version of the root key at a preset period, while the old version of the root key only supports the decryption of historical data.

8. The unified cryptographic service method supporting cross-level sharing according to claim 7, characterized in that: Also includes: S6, set up a key rotation mechanism: The KMS service scans the DEK metadata marked as automatically rotated in the distributed database at a preset period and performs rotation operations according to preset trigger conditions, including time-driven triggering and usage-driven triggering. Time-driven triggers are executed according to a preset rotation cycle, which may be once a day, once a week, or once a month. Usage-driven triggering executes when the number of times DEK is used exceeds a preset threshold. When performing a rotation, KMS generates a new version of DEK within the HSM cluster, encrypts the newly generated DEK using the current KEK, stores the encrypted DEK in the distributed database, and updates the version number and creation time in the key metadata. Mark the old version of DEK as decryption-only, so it can only be used to decrypt historical data.

9. The unified cryptographic service method supporting cross-level sharing according to claim 8, characterized in that: Also includes: S7, configure a multi-tenant resource isolation mechanism: At the network layer, a Calico network strategy is adopted, configuring an independent network namespace for each tenant to restrict network communication between different tenant Pods, allowing only controlled access through the API gateway; The storage layer adopts a schema isolation mode, creating an independent database schema or tablespace for each tenant in the distributed database. The database schema contains the corresponding tenant's key metadata table, audit log table, and permission configuration table. At the computing resource layer, the Kubernetes ResourceQuota mechanism is used to set CPU quotas, memory quotas, and storage quota limits for each tenant. In the HSM resource layer, independent key partitions or key slots are allocated to different tenants, and physical isolation of keys between tenants is ensured through the access control lists (ACLs) within the HSM. At the audit layer, an independent audit log stream is generated for each tenant, using different log storage paths and access permissions, so that tenants can only query their own operation audit records.

10. A unified cryptographic service system supporting cross-level sharing, characterized in that, include: At least one processing unit; for executing instructions to implement the unified cryptographic service method supporting cross-level sharing as described in any one of claims 1 to 9.

Images