Cooperative scheduling system and method for cryptographic operation resources based on distributed SSD (Solid State Disk)

Abstract

The invention discloses a distributed SSD (Solid State Disk)-based password operation resource collaborative scheduling system and method in the technical field of computer passwords. A service interface layer of the system is used for receiving a password operation request, sending the password operation request to a scheduling layer and returning a feedback operation result to a client through the service interface layer; the execution layer comprises a distributed SSD cluster formed by network interconnection of a plurality of SSD nodes, available cryptographic algorithm resources in the node are reported on each node, and the execution layer has the capability of calling a hardware cryptographic engine in a chip to execute operation; the resource management layer is used for maintaining reported information and forming a global view of dynamic password resources; and the scheduling layer is used for receiving the cryptographic operation request and selecting the SSD node to execute a cryptographic operation request task according to the global view and the scheduling strategy. According to the system, idle resources are integrated, the performance and availability of the system are improved along with the increase of the number of nodes, and the effects of low cost, high expansibility and availability and high resource utilization rate are achieved.

Description

Technical Field

[0001] This invention relates to the field of computer cryptography technology, and in particular to a collaborative scheduling system and method for cryptographic computing resources based on distributed SSD. Background Technology

[0002] A traditional encryption machine is a physical device specifically designed to protect and manage digital keys and perform encryption operations. Its core tasks are to securely generate, store, and use keys, and to perform encryption and decryption operations at high speed.

[0003] Traditional encryption machines are essentially centralized security devices, typically standalone physical enclosures deployed as dedicated "black boxes" in data centers. All cryptographic operations are centralized within this single hardware entity. As a shared security service node, the traditional encryption machine provides centralized key management and cryptographic operations for multiple application servers across the network. All critical encryption, decryption, signing, and verification operations must be routed to this central node. The entire system's security foundation is built upon this single encryption machine. It becomes the "trust anchor" or "security root" of the entire application ecosystem.

[0004] Traditional encryption machines are hardware devices specifically designed for key management and performing high-strength cryptographic operations. While offering high performance and security, they also have some inherent drawbacks: 1. High cost: Dedicated hardware design, manufacturing, and certification are costly. 2. Poor scalability: Performance is limited by a single device, making horizontal scaling difficult and typically requiring stacking devices, leading to complex management. 3. Single point of failure risk: As a centralized device, a failure will disrupt all cryptographic services that rely on it. 4. Uneven resource utilization: During off-peak hours, the encryption machine's computing resources may be idle, resulting in wasted resources. Summary of the Invention

[0005] This application provides a distributed SSD-based collaborative scheduling system and method for cryptographic computing resources, which solves the problems of high cost, poor scalability, low resource utilization, and single point of failure risk of traditional encryption machines, and achieves the effects of low cost, high scalability and availability, and high resource utilization.

[0006] This application provides a distributed SSD-based cryptographic computing resource collaborative scheduling system, including: a service interface layer, an execution layer, a resource management layer, and a scheduling layer; The service interface layer is used to accept cryptographic operation requests from external clients and send them to the scheduling layer. It is also used to return the operation results (such as ciphertext and signature values) to the client via API. The execution layer includes a distributed SSD cluster, which is composed of multiple interconnected SSD nodes. Each SSD node is equipped with an SSD resource proxy module, which is used to discover, monitor and report available cryptographic algorithm resources within the SSD node. Each SSD node has the ability to call the on-chip hardware cryptographic engine to perform cryptographic operations. The resource management layer, which includes the resource registry, is used to receive and maintain information reported by all online SSD resource agent modules, forming a global view of dynamic password resources. The scheduling layer includes a cryptographic task scheduler, which receives cryptographic operation requests from the service interface layer and selects several SSD nodes to execute the cryptographic operation request tasks based on the global view provided by the resource registry, the preset scheduling strategy, and the requirement attributes of the cryptographic operation request itself.

[0007] The beneficial effects of the above embodiments are as follows: the collaborative scheduling system integrates the idle cryptographic resources of distributed SSDs, improves resource utilization, significantly reduces costs, and the system performance and availability improve with the increase of the number of SSD nodes, exhibiting scalability and high availability. It solves the problems of high cost, poor scalability, single point of failure, and low resource utilization of traditional encryption machines, achieving the effects of low cost, high scalability and availability, and high resource utilization. Furthermore, the distributed key management ensures that the asymmetric private key or symmetric key never leaves the hardware, resulting in extremely high security.

[0008] Based on the above embodiments, this application can be further improved as follows: In one embodiment of this application, the service interface layer includes a unified cryptographic service API, through which the service interface layer connects to external clients. The unified cryptographic service API provides a standard set of API interfaces that are independent of specific physical SSDs, isolating the internal and external systems. External clients submit cryptographic computation tasks by calling these APIs without needing to know which specific SSD node is executing the backend.

[0009] In one embodiment of this application, the SSD node is a physical server or storage array equipped with SSD devices. This reuses existing infrastructure, significantly reducing system deployment costs and improving the utilization rate of idle resources.

[0010] In one embodiment of this application, the available cryptographic algorithm resources include supported algorithm types, computational performance, and current load status; the algorithm types include, but are not limited to, AES, RSA, SM4, and SHA. Clearly defining the types, performance, and load status of available cryptographic algorithm resources provides the scheduling layer with accurate node capability data, optimizes task allocation strategies, and improves the matching degree and execution efficiency of cryptographic operations.

[0011] In one embodiment of this application, the SSD resource proxy module is deployed on each SSD device or provided directly by the SSD firmware. The SSD resource proxy module, deployed on the SSD device or firmware, enables real-time monitoring and reporting of node status, ensuring the accuracy of the global resource view.

[0012] In one embodiment of this application, the scheduling strategy includes load balancing and proximity computing; the requirements attributes of the cryptographic operation request itself include algorithm type, data volume, and priority. The load balancing strategy balances the node load and avoids resource idleness or overload; the proximity computing strategy reduces data transmission latency; and the combination of request attributes (algorithm type, data volume, priority) enables precise scheduling, improving resource utilization and service quality.

[0013] In one embodiment of this application, the scheduling layer further includes a key security management module, which manages the generation and distribution of keys. The SSD nodes can also be used to perform local cryptographic operations. The key security management module supports two key management methods: Method 1: The key security management module acts as a centralized service, responsible for the secure generation, distribution, and management of asymmetric key pairs and symmetric keys. Centralized management facilitates auditing and integration with existing systems, meeting centralized management requirements. The working keys distributed to the SSD nodes are encrypted and decrypted only within the secure environment of the SSD. Centralized key management facilitates integration with existing infrastructure, meeting the requirements of centralized auditing and management. Method 2: The key security management module generates and securely stores a global root master key (K_master) for symmetric operations. This root master key is pre-installed in all authorized SSD nodes using a secure method (such as digital envelope technology based on the public keys of each SSD node). The SSD nodes generate asymmetric key pairs locally for asymmetric operations and register the public keys with the resource registry center of the resource management layer.

[0014] This application also provides a method for collaborative scheduling of cryptographic computing resources based on distributed SSDs, which, based on the aforementioned collaborative scheduling system, includes the following steps: S1: An external client submits a cryptographic operation request to the cryptographic task scheduler through the service interface layer; S2: The cryptographic task scheduler queries and obtains a global view through the resource registry center of the resource management layer, and selects several target SSD nodes according to the preset scheduling strategy and the requirement attributes of the cryptographic operation request itself. S3: The selected SSD node completes key decryption or retrieval according to the requirements via method one or method two, performs cryptographic operations, and returns the operation results (such as ciphertext and signature value) to the cryptographic task scheduler. Method 1: The key management module generates an asymmetric key pair and a symmetric key, and sends the asymmetric public key, the encrypted asymmetric private key, and the symmetric key to the SSD node. The SSD node performs local cryptographic operations to decrypt the encrypted asymmetric private key and the symmetric key, and performs local cryptographic operations. Method 2: If it is a symmetric operation, the SSD node independently derives the same session key using the locally securely stored K_master and the publicly available data identifier; if it is an asymmetric operation, the cryptographic task scheduler specifies the use of the asymmetric key pair stored locally on the SSD node. S4: The cryptographic task scheduler returns the computation results to the external client via API. Attached Figure Description

[0015] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0016] Figure 1 This is a structural block diagram of a distributed SSD-based cryptographic computing resource collaborative scheduling system according to an embodiment of this application; Figure 2 This is a schematic diagram of the internal interaction of the SSD node in the embodiments of this application; Figure 3 This is a flowchart illustrating the steps of a distributed SSD-based collaborative scheduling method for cryptographic computing resources in an embodiment of this application. Detailed Implementation

[0017] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0018] Example: like Figure 1 As shown, a collaborative scheduling system for cryptographic computing resources based on distributed SSDs includes: a service interface layer, an execution layer, a resource management layer, and a scheduling layer. The service interface layer accepts cryptographic computation requests from external clients and sends them to the scheduling layer. It also receives computation results (such as ciphertext and signature values) from the scheduling layer and sends them to external clients. The service interface layer includes a unified cryptographic service API, through which it connects with external clients. This unified cryptographic service API is a standard set of API interfaces provided externally, independent of the specific physical SSD. External clients (including external applications) submit cryptographic computation tasks by calling these APIs, without needing to know which specific SSD node is executing the computations.

[0019] The execution layer comprises a distributed SSD cluster, which consists of a network of interconnected SSD nodes with SSDs installed. Each SSD node has an SSD resource proxy module for discovering, monitoring, and reporting available cryptographic algorithm resources within the node (supported algorithm types include, but are not limited to, AES, RSA, SM4, and SHA; computational performance; and current load status). Each SSD node has the capability to invoke the hardware cryptographic engine within its local SSD controller chip to perform computations. The SSD resource proxy module is either deployed on each SSD device or provided directly by the SSD firmware.

[0020] The resource management layer includes a resource registry, which is a centralized or distributed service used to receive and maintain real-time status and capability information reported by all online SSD resource agent modules, forming a dynamic global view of cryptographic resources. The scheduling layer serves as the core decision-making center, comprising a cryptographic task scheduler and a key security management module. The cryptographic task scheduler processes requests and queries the resource registry, obtaining a list of available nodes and key capability information through a global view. The key security management module interacts with the external KMS and manages key materials. Specifically, the cryptographic task scheduler receives cryptographic operation requests from the service interface layer and selects several SSD nodes to execute the cryptographic operation request tasks based on the global view provided by the resource registry, preset scheduling strategies (such as load balancing and proximity computing), and the specific requirements of the cryptographic operation request itself (such as algorithm type, data volume, and priority). The key security management module, as a centralized service, is responsible for the secure generation, distribution, and lifecycle management of keys during task execution. The key security management module integrates with the external KMS to ensure the security of the root key. Working keys distributed to SSD nodes are encrypted and decrypted and used only within the secure environment of the SSD.

[0021] It should be noted that the key generation and management of this collaborative scheduling system have two methods: Method 1: After receiving a request, the cryptographic task scheduler selects an SSD node. The key management module generates an asymmetric key pair (P_kms and S_kms) and a symmetric key via KMS. The selected SSD node internally generates an asymmetric key pair (P_ssd and S_ssd). P_ssd is registered with the resource management layer. The key management module uses P_ssd to encrypt the S_kms and symmetric key generated by KMS and sends them to the selected SSD node. Within a secure area, the selected SSD node uses S_ssd to decrypt the encrypted S_kms and symmetric key, performs local cryptographic operations, and returns the results (ciphertext and signature value) to the cryptographic task scheduler. The cryptographic task scheduler then returns the results to the external client application via API. Features: Strong control, easy auditing, and high integration with traditional systems.

[0022] Method 2: For symmetric operations, the cryptographic task scheduler receives a request and selects an SSD node. The selected SSD node uses its locally securely stored K_master and publicly available data identifier to independently derive the same session key locally using its hardware capabilities (such as a true random number generator). For asymmetric operations, the cryptographic task scheduler specifies the use of the asymmetric key pair generated and stored locally by the SSD node. The asymmetric public key is registered in the resource management layer. Features: The asymmetric private key and symmetric key never leave the local hardware, providing extremely high security, suitable for distributed identity and signature, and data encryption / decryption scenarios.

[0023] It should be noted that the core computing power of this collaborative scheduling system comes from the SSD cluster, but the upper-level logic such as scheduling and management needs to be carried by other hardware. For example, the scheduling layer, resource management layer, and service interface layer are generally deployed on general application servers.

[0024] In this collaborative scheduling system, SSD nodes refer to physical servers or storage arrays that have SSD devices installed. Internal interactions within SSD nodes are as follows: Figure 2 As shown: As a secure computing unit, the SSD controller chip's secure area is its core. It not only securely stores and decrypts the working keys issued by the central control (Method 1), but also integrates a True Random Number Generator (TRNG) and a key generator, enabling the SSD to independently and securely create and store its own keys (Method 2). The cryptographic algorithm hardware engine and the secure area are tightly coupled through an internal high-speed data path, ensuring that the plaintext key can be directly accessed by the cryptographic engine without entering the main system memory, achieving the highest level of security.

[0025] like Figure 1 , 3 As shown, a collaborative scheduling method for a distributed SSD-based cryptographic computing resource collaborative scheduling system includes the following steps: S1: External clients submit cryptographic operation requests to the cryptographic task scheduler in the scheduling layer through the unified cryptographic service API in the service interface layer; S2: The cryptographic task scheduler queries and obtains a list of available nodes through the resource registry center of the resource management layer, and selects several target SSD nodes according to the preset scheduling strategy and the requirements of the cryptographic operation request itself. S3: The selected SSD node (or node group for parallel computing) receives the task and executes the key task according to the requirements of either method one or method two. That is, it completes key decryption or retrieval within the hardware security area of ​​its main control chip and performs cryptographic operations. Method 1: The key management module generates an asymmetric key pair and a symmetric key via KMS, and sends the asymmetric public key, the encrypted asymmetric private key, and the symmetric key to the selected SSD node. The SSD node, within a secure area, decrypts the encrypted asymmetric private key and symmetric key, performs local cryptographic operations, and returns the operation results (such as ciphertext and signature value) to the cryptographic task scheduler; it also returns the asymmetric public key information to the cryptographic task scheduler.

[0026] Method 2: For symmetric operations, the cryptographic task scheduler receives a request and selects an SSD node. The selected SSD node uses its locally securely stored K_master and publicly available data identifier to independently derive the same session key locally using its hardware capabilities (such as a true random number generator). For asymmetric operations, the cryptographic task scheduler specifies the use of the asymmetric key pair generated and stored locally by the SSD node. The asymmetric public key is registered in the resource management layer. Within the secure area, the SSD node performs symmetric operations using the independently derived session key, or performs asymmetric operations using the locally generated and stored asymmetric key, and returns the results (such as ciphertext or signature value) to the cryptographic task scheduler. S4: The cryptographic task scheduler returns the computation results to the external client via API.

[0027] The technical solutions described in the embodiments of this application have at least the following technical effects or advantages: 1. This invention can significantly reduce costs: It makes full use of the idle computing power of SSDs that are already widely deployed in existing IT infrastructure, eliminating the need to purchase or reducing the purchase of expensive dedicated encryption machines, and realizing a converged architecture of "storage as computing".

[0028] 2. This invention features scalability and high availability: system performance and availability improve with the increase in the number of SSD nodes, achieving true horizontal scaling and completely eliminating the risk of single point of failure in centralized encryption machines.

[0029] 3. This invention improves resource utilization: it transforms the "private" computing power, which was originally used only for storage encryption, into "public" computing power that can be used by the entire network, greatly improving the computing density and resource utilization of the overall infrastructure.

[0030] 4. This invention features low latency and high performance: It directly utilizes the hardware cryptographic engine of the SSD controller to provide energy-efficient computing. "Proximity-based computing" can be achieved through a scheduler, reducing data transmission and lowering latency.

[0031] 5. This invention proposes two flexible and enhanced key management security models: Method 1: Centralized key management, which facilitates integration with existing infrastructure and meets the requirements of centralized auditing and management.

[0032] Method 2: Distributed key management provides ultimate security. The core private key never leaves the hardware environment in which it was generated, fundamentally eliminating the risk in the key distribution process. It is suitable for scenarios with extremely high requirements for identity security and signature non-repudiation.

[0033] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A collaborative scheduling system for cryptographic computing resources based on distributed SSDs, characterized in that, include: Service interface layer, execution layer, resource management layer, and scheduling layer; The service interface layer is used to accept cryptographic operation requests from external clients and send them to the scheduling layer. It is also used to return the operation results (such as ciphertext and signature values) to the client via API. The execution layer includes a distributed SSD cluster, which is composed of multiple interconnected SSD nodes. Each SSD node is equipped with an SSD resource proxy module, which is used to discover, monitor and report available cryptographic algorithm resources within the SSD node. Each SSD node has the ability to perform cryptographic operations. The resource management layer, which includes the resource registry, is used to receive and maintain information reported by all online SSD resource agent modules, forming a global view of dynamic password resources. The scheduling layer includes a cryptographic task scheduler, which receives cryptographic operation requests from the service interface layer and selects several SSD nodes to execute the cryptographic operation request tasks based on the global view provided by the resource registry, the preset scheduling strategy, and the requirement attributes of the cryptographic operation request itself.

2. The cryptographic operation resource collaborative scheduling system according to claim 1, characterized in that: The service interface layer includes a unified cryptographic service API, through which the service interface layer connects to external clients.

3. The cryptographic operation resource collaborative scheduling system according to claim 1, characterized in that: The available cryptographic algorithm resources include supported algorithm types, computational performance, and current load status; the algorithm types include, but are not limited to: AES, RSA, SM4, and SHA.

4. The cryptographic operation resource collaborative scheduling system according to claim 1, characterized in that: The SSD node is a physical server or storage array with SSD devices installed.

5. The cryptographic operation resource collaborative scheduling system according to claim 4, characterized in that: The SSD resource proxy module is deployed on each SSD device or provided directly by the SSD firmware.

6. The cryptographic operation resource collaborative scheduling system according to claim 1, characterized in that: The scheduling strategy includes load balancing and proximity computing; the requirements of the cryptographic operation request itself include algorithm type, data volume, and priority.

7. The cryptographic operation resource collaborative scheduling system according to any one of claims 1-6, characterized in that: The scheduling layer also includes a key security management module, which manages the generation and distribution of keys. This module supports two key management methods: Method 1: The key security management module is integrated with an external KMS as a centralized service, responsible for the secure generation, distribution and management of asymmetric key pairs and symmetric keys; Method 2: The key security management module is integrated with an external KMS to generate and securely store a global root master key for symmetric operations.

8. A method for collaborative scheduling of cryptographic computing resources based on distributed SSDs, characterized in that: The cryptographic operation resource collaborative scheduling system as described in claim 7 includes the following steps: S1: An external client submits a cryptographic operation request to the cryptographic task scheduler through the service interface layer; S2: The cryptographic task scheduler queries and obtains a global view through the resource registry center of the resource management layer, and selects several target SSD nodes according to the preset scheduling strategy and the requirement attributes of the cryptographic operation request itself. S3: The selected SSD node completes key decryption or calls and executes cryptographic operations according to the requirements through method one or method two, and returns the operation result to the cryptographic task scheduler; Method 1: The key management module obtains the asymmetric key pair and the symmetric key, sends the asymmetric public key, the encrypted asymmetric private key, and the symmetric key to the SSD node, and the SSD node performs local cryptographic operations to decrypt the encrypted asymmetric private key and the symmetric key. Method 2: If it is a symmetric operation, the SSD node independently derives the same session key using the locally securely stored K_master and the publicly available data identifier; if it is an asymmetric operation, the cryptographic task scheduler specifies the use of the asymmetric key pair stored locally on the SSD node. S4: The cryptographic task scheduler returns the calculation result to the external client through the service interface layer.

9. The method for collaborative scheduling of cryptographic computing resources according to claim 8, characterized in that: In the second method, the asymmetric public key is registered in the resource management layer.

Images