A cloud storage encryption offloading method based on in-network computing

Abstract

The application discloses a cloud storage encryption offloading method based on in-network computing. The application faces a storage-computing separation cloud storage architecture, an access coordination entity receives a write request or a read request of a service initiation entity, and sends to-be-processed data to a computing processing entity; the computing processing entity is internally provided with an in-network encryption and decryption data plane of a neighboring network path, a control plane thereof generates a request context containing an encryption or decryption mode according to a request, a data plane executes encryption or decryption processing on to-be-processed data according to the request context, and returns processing result data to the access coordination entity along the network path; and the access coordination entity sends the encrypted ciphertext data to a storage service entity for persistence according to a request type, or returns the decrypted plaintext data to the service initiation entity. The application offloads encryption and decryption computing from a host CPU to a network data plane, reduces redundant data movement, reduces host resource occupation, improves cloud storage access throughput and reduces end-to-end delay.

Description

Technical Field

[0001] This invention relates to the field of cloud storage and data security technology, and in particular to a cloud storage encryption offloading method based on online computing. Background Technology

[0002] With the increasing prevalence of cloud-native architectures and the continuous improvement of data center resource pooling, cloud storage systems are evolving from traditional tightly coupled deployment methods to a compute-storage separation architecture. In this architecture, business request access, data organization, computation processing, and persistent storage are collaboratively completed by different functional entities, improving resource utilization and system scalability. Simultaneously, data security compliance requirements are becoming increasingly stringent, and data encryption has become a fundamental capability of cloud storage rather than an optional feature. However, when data objects are fully encrypted, encryption and decryption operations introduce significant computational overhead throughout the read / write path, directly impacting system throughput, end-to-end latency, and the resource consumption of the compute-side host. In high-bandwidth access scenarios, encrypted computation may even replace network transmission as the primary performance bottleneck.

[0003] Existing cloud storage encryption solutions mainly fall into two categories. The first category is software encryption solutions based on the host CPU. This solution is simple to deploy and has good compatibility, but encryption and decryption operations share host CPU resources with tasks such as request parsing, protocol stack processing, cache management, data fragmentation, and routing scheduling. In environments with large object transmissions, high-concurrency access, and high-speed networks, software encryption can easily lead to decreased throughput, increased end-to-end latency, and intensified resource contention on the host side. The second category is encryption solutions based on PCIe-mounted hardware acceleration devices. This solution offloads some encryption computations to an external accelerator, thereby reducing the computational pressure on the host CPU. However, traditional external accelerators are usually located outside the host memory and network transmission path, requiring data to be moved back and forth between the host memory and the acceleration device; after encryption or decryption, the processing result may still return to the host memory and then be forwarded by the host-side protocol stack or network interface. Therefore, although this type of solution improves the efficiency of a single encryption computation, it does not fundamentally change the basic pattern of "critical data paths revolving around the host," and system-level benefits are limited by redundant data movement and additional path overhead.

[0004] Furthermore, in compute-debugging cloud storage scenarios, the access coordination entity typically undertakes system-level responsibilities such as request orchestration, storage resource location, persistence organization, and business response return. Simply forwarding encryption results directly from the compute processing entity to the storage service entity, or directly returning decryption results to the business initiating entity, could disrupt the original access scheduling, data organization, and result aggregation logic. Therefore, how to migrate compute-intensive encryption and decryption processing to the data plane of a nearby network without altering the system-level orchestration responsibilities of the access coordination entity, and how to avoid redundant data migration between host software paths and traditional external acceleration paths, has become a pressing issue in the field of cloud storage encryption technology. Summary of the Invention

[0005] The purpose of this invention is to provide a cloud storage encryption offloading method based on online computing, in order to solve at least some of the problems existing in the prior art.

[0006] A technical solution, a cloud storage encryption offloading method based on online computing, includes the following steps:

[0007] The access coordination entity receives cloud storage access requests from the business initiating entity, parses the cloud storage access requests to determine the data to be processed, the target storage service entity, and the business initiating entity;

[0008] The access coordination entity sends the data to be processed to the computing processing entity. The computing processing entity has an on-network encryption and decryption data plane with a nearby network path, and the control plane of the computing processing entity generates a request context based on the cloud storage access request.

[0009] In the network encryption / decryption data plane, encryption or decryption processing is performed on the data to be processed according to the request context to obtain the processing result data. The computing processing entity then returns the processing result data to the access coordination entity along the network path.

[0010] Depending on the type of cloud storage access request, the access coordination entity will send the encrypted ciphertext data to the target storage service entity for persistence, or return the decrypted plaintext data to the business initiating entity.

[0011] Beneficial effects: By offloading encryption and decryption processing to the adjacent network data plane of the computing processing entity and uniformly returning it to the access coordination entity, this invention reduces host CPU resource consumption and redundant data migration, while improving cloud storage access throughput and reducing end-to-end latency. Attached Figure Description

[0012] Figure 1 This is a flowchart of the overall solution of the present invention. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] like Figure 1 As shown, this embodiment describes in detail the data processing flow of a cloud storage encryption offloading method based on on-network computing, specifically including:

[0015] S1: The access coordination entity receives cloud storage access requests from the business initiating entity, parses the cloud storage access requests to determine the data to be processed and the target storage service entity and the business initiating entity.

[0016] In this application, the starting point of the cloud storage access path is the access coordination entity. As the unified coordination entry point in the compute-storage separation cloud storage architecture, the access coordination entity first undertakes the task of receiving cloud storage access requests from the business initiating entity. The business initiating entity can be a client, application service, tenant business process, or upper-layer data access component, and the cloud storage access requests it initiates include at least two types: write requests and read requests. A typical write request includes: the raw plaintext data to be written, an object identifier (e.g., bucket name and key-value combination, file path, or data block number), access permission information, and optional metadata tags. A typical read request includes: an object identifier, a read range (e.g., byte range or shard index), and access permission information.

[0017] Specifically, after receiving the aforementioned request via a network protocol stack (such as TCP / IP, RDMA, or a custom RPC protocol), the access coordination entity performs the first-phase parsing operation. The goal of the parsing operation is to extract the key information necessary for subsequent processing from the original request message. For example, for a write request, the access coordination entity separates the payload of the plaintext data to be written from the request, and simultaneously parses out the object identifier and storage policy requirements. For a read request, the access coordination entity mainly extracts the object identifier and the read range. At this point, the data to be processed has not yet been obtained from the storage service entity, and metadata location needs to be completed first.

[0018] Furthermore, the access coordination entity needs to determine two elements during the parsing process: the "target storage service entity" and the "business initiating entity." For write requests, the target storage service entity refers to one or more storage nodes, object storage services, or distributed file system data nodes that ultimately persist the encrypted data; the business initiating entity acts as the source of the request, used to return the write result later. For read requests, the target storage service entity is the storage backend that stores the encrypted data, while the business initiating entity is the caller that needs to receive the decrypted plaintext data. In this scheme, even if the encrypted data for the read request has not yet been actually obtained, the access coordination entity will pre-determine the location information of the target storage service entity based on the object metadata, preparing for subsequent data reading.

[0019] In one optional implementation, the access coordination entity also performs a security policy determination during the parsing phase. Specifically, it queries the object identifier to determine whether encryption protection is enabled, the type of algorithm used (e.g., AES-256 or SM4), and the key identifier. If the request itself carries encryption policy parameters, the policy in the request takes precedence. Through the above parsing and determination operations, the access coordination entity produces an internal data structure that includes at least: request type (read / write), object identifier, reference to the data to be processed (write requests directly carry a plaintext payload, while read requests are temporarily empty), a list of target storage service entity addresses, the network address of the service initiating entity, and security policy parameters.

[0020] S2: The access coordination entity sends the data to be processed to the computing processing entity. The computing processing entity has an on-network encryption and decryption data plane with a nearby network path, and the control plane of the computing processing entity generates a request context based on the cloud storage access request.

[0021] In this scheme, after request parsing is completed, the access coordination entity does not directly perform encryption / decryption operations on the data to be processed. Instead, it sends the data to a specially designed computing processing entity. The computing processing entity is a data plane acceleration node deployed in a compute-in-memory separation architecture, which is internally configured with an on-network encryption / decryption data plane with a proximity network path. The proximity network path means that the data plane is located on the necessary network path for data to flow from the access coordination entity to the storage or client. For example, it is integrated into a smart network card, a data processing unit (DPU), an infrastructure processing unit (IPU), or a field-programmable gate array (FPGA), thereby avoiding repeated data transfer between host memory and external accelerators.

[0022] Specifically, the access coordination entity prepares the data to be sent based on the request type. For write requests, the data to be sent is the plaintext data block extracted from the original request; for read requests, the access coordination entity first needs to initiate an encrypted data read operation to the storage backend based on the target storage service entity address determined in S1. After the encrypted data is returned to the access coordination entity, it is then used as the data to be sent. That is to say, in the read request scenario, the data to be processed in S2 is actually the encrypted data obtained by the access coordination entity from the storage service entity. This application adopts the same data sending mechanism for both write and read requests: the access coordination entity encapsulates the data to be processed into one or more network packets, and each packet header carries a unique context ID (e.g., a request number assigned by the access coordination entity) that identifies the request.

[0023] Furthermore, simultaneously with or slightly earlier than data transmission, the access coordination entity interacts with the control plane of the computing processing entity. The control plane of the computing processing entity is a software logic entity running in the host CPU or management core, responsible for handling low-frequency, stateful, and policy-based tasks. According to one aspect of this application, the control plane generates a request context based on request information provided by the access coordination entity. The request context is a data structure describing the semantics of the current cloud storage access request processing, exemplarily including the following fields: request number, request type (write / read / bypass), operation mode (encryption / decryption / bypass), algorithm identifier (e.g., 0x01 represents AES-256-ECB, 0x02 represents SM4-ECB), key identifier (pointing to a key slot in a key management service), data length, data block number, last data block flag, and return target address.

[0024] In a preferred embodiment, the process of the control plane generating a request context includes: first, receiving a control message from the access coordination entity, which contains the request parsing result and security policy; then, the control plane automatically determines the operation mode based on the request type: a write request corresponds to an encryption mode, and a read request corresponds to a decryption mode; next, the control plane obtains or verifies a key identifier from a local key cache or an external key management service and fills it into the context; finally, the control plane distributes the generated request context to the context table of the on-network encryption / decryption data plane, so that the data plane can quickly match it when processing subsequent data packets. The context table is typically indexed by the request number and stored in the on-chip memory or a dedicated lookup table of the data plane device.

[0025] Furthermore, the network packets containing data to be processed sent by the access coordination entity also carry the same request number. Thus, when a data packet arrives at the on-network encryption / decryption data plane of the computing processing entity, the data plane can find the pre-configured request context based on the request number in the packet header, thereby determining which algorithm, key, and encryption or decryption operation should be used. This scheme, through the separation of the control plane and data plane and the pre-configuration mechanism of the request context, decouples control logic from high-speed data processing, avoids repeatedly carrying complete policy information in each data packet, and effectively reduces processing overhead.

[0026] S3: On the network encryption / decryption data plane, the data to be processed is encrypted or decrypted according to the request context to obtain the processing result data. The computing processing entity then returns the processing result data to the access coordination entity along the network path.

[0027] In this embodiment, after the data packet stream to be processed is sent from the access coordination entity to the computing processing entity, the in-network encryption / decryption data plane inside the computing processing entity begins to execute core data processing tasks. The in-network encryption / decryption data plane is typically implemented by a hardware acceleration engine (such as the regular expression engine in the DPU, the pipeline logic in the FPGA, or the encryption offloading module in the smart network card), and its design goal is to process network data at line speed without relying on the scheduling of the host CPU.

[0028] Specifically, after receiving each data packet, the data plane first extracts the request number from the packet header. Then, the data plane uses this request number to perform a lookup and matching operation in the local context table. If the match is successful, it retrieves the request context record pre-configured in the control plane of S2, which explicitly indicates the operation mode (encryption or decryption), algorithm identifier, and key identifier. If the match fails (e.g., the request context has not been configured or has expired), the data plane will trigger an exception handling process, the specific exception handling method of which will be described in subsequent steps.

[0029] According to one aspect of this application, for a write request, the operation mode in the request context is set to encrypted mode. The data plane selects the corresponding encryption engine (e.g., an AES-256-ECB hardware core or an SM4-ECB hardware core) based on the algorithm identifier and reads the corresponding key material from the local key cache based on the key identifier. Then, the data plane performs block encryption processing on the received plaintext data payload: the plaintext is divided into blocks according to the block length of the encryption algorithm (e.g., 16 bytes for AES), and ciphertext blocks are generated sequentially through the encryption engine. No host CPU involvement is required during the encryption process; all operations are completed on the path of the data stream passing through the network interface card. For example, when using AES-256-ECB mode, each plaintext block is encrypted independently without feedback dependency, suitable for high-throughput parallel processing. After encryption, the data plane repackages the ciphertext blocks into network packets, maintaining the same request number and header information.

[0030] For read requests, the operation mode is decryption mode. The data plane receives encrypted data (from the storage service entity) and, based on the algorithm identifier and key identifier in the request context, calls the decryption engine to perform decryption operations on the encrypted blocks, recovering the original plaintext data. The decrypted plaintext data is then encapsulated into a network packet.

[0031] Furthermore, regardless of whether it's encryption or decryption, the processed result data is not directly sent from the computing entity to the storage service entity or the service initiating entity. Instead, according to one aspect of this application, the computing entity must return all processed result data to the access coordination entity along the network path. This is because the access coordination entity undertakes the system-level request orchestration and result aggregation responsibilities in the compute-storage separation architecture. Specifically, after the data plane completes encryption and decryption processing, it sets the destination address of the result message to the network address of the access coordination entity and the source address to the address of the computing entity itself, and then sends it out through the switching network. Thus, the access coordination entity, as the unified receiving point for all encryption and decryption results, can maintain the original storage scheduling and response return logic without disruption.

[0032] In one alternative implementation, for large object chunked transmission scenarios, the data plane processes and returns each data block independently, while setting a last data block flag in the request context of the last data block. The access coordination entity can use this flag to determine whether all processing results for a complete request have been received, thereby enabling reassembly.

[0033] S4: Depending on the type of cloud storage access request, the access coordination entity sends the encrypted ciphertext data to the target storage service entity for persistence, or returns the decrypted plaintext data to the business initiating entity.

[0034] In this application, after receiving the processing result data returned from the computing entity, the access coordination entity does not perform additional encryption / decryption operations. Instead, it directly executes the final forwarding or response operation based on the type of the original cloud storage access request. This step is designed to ensure that the encryption offloading process does not disrupt the original request orchestration, storage resource location, and result aggregation logic of the cloud storage system.

[0035] Specifically, for write request scenarios: the processing result data received by the access coordination entity is encrypted data (obtained by encrypting plaintext). The access coordination entity first associates the request number in the message header with the original write request context stored in S1, obtaining the target storage service entity's address list, storage organization strategy (e.g., replica placement rules, sharding merging method), and confirmation requirements upon completion of the write operation. Then, the access coordination entity sends the encrypted data to the target storage service entity. The sending method can be direct forwarding, sharding upload, or via a storage gateway protocol (such as S3, NFS, or CephRGW). After completing the persistent write of the encrypted data, the storage service entity typically returns a write confirmation (e.g., ETag or version number). Upon receiving the confirmation, the access coordination entity returns a write success response to the original "business initiating entity." In this solution, the business initiating entity only interacts with the access coordination entity throughout the process and is unaware of the existence of the computing processing entity, thus maintaining the compatibility of the cloud storage access interface.

[0036] For read request scenarios: the processing result data received by the access coordination entity is plaintext data (obtained by decrypting ciphertext). The access coordination entity also associates the original read request with the request number, obtaining the network address and response format requirements of the business initiating entity. Then, the access coordination entity encapsulates the plaintext data into one or more response messages according to the reading protocol (e.g., HTTP range response, NFSREAD reply, or custom data block merging) and returns them to the business initiating entity. Before returning, the access coordination entity can also perform optional data reassembly operations: if the original read request was split into multiple blocks for separate reading and decryption, these blocks need to be sequentially assembled into a complete object before being returned. In this scheme, the decryption result is uniformly returned to the access coordination entity, allowing the above reassembly operation to be completed on a centralized node, simplifying the client's processing logic.

[0037] In a preferred embodiment, the access coordination entity also performs an integrity check upon receiving the processed result data. For example, for a write request, it can compare the ciphertext length with the original plaintext length to see if they meet the padding requirements of the encryption algorithm; for a read request, it can check whether the plaintext data contains the expected object header information. If the check fails, the access coordination entity can request the computing processing entity to reprocess (retry), or downgrade to using the host CPU software path for encryption and decryption.

[0038] In a preferred embodiment, in a bypass request scenario, if the cloud storage access request does not require encryption / decryption processing (e.g., accessing a public object or already encrypted by the client), the access coordination entity will set its operation mode to bypass mode in S2. After receiving the bypass request context, the computing processing entity's on-network encryption / decryption data plane does not change the data content, only performing reception and forwarding. Correspondingly, in S4, the processing result data received by the access coordination entity is exactly the same as the original data to be processed. At this time, the access coordination entity can directly forward the data to the storage service entity (write bypass) or return it to the service initiating entity (read bypass), without any encryption or decryption operations.

[0039] According to another aspect of this application, the process for writing a request for encrypted offloading is as follows:

[0040] In this application, when the access coordination entity determines that the cloud storage access request is a write request, it executes a dedicated encrypted offloading process optimized for write paths. Specifically, the data to be processed carried in the write request is plaintext data, i.e., raw user data blocks without encryption protection. After parsing the write request, the access coordination entity extracts this plaintext data from the request payload and uses it as the data content subsequently sent to the computing processing entity.

[0041] According to a further improvement of this embodiment, the control plane of the computation processing entity explicitly sets the operation mode in the request context to "encryption mode" based on the semantics of the write request. This means that after receiving plaintext data, the subsequent on-net encryption / decryption data plane will call the encryption engine to perform encryption operations, rather than decryption or bypass operations. When generating the request context, the control plane also extracts the algorithm identifier and key identifier from the security policy of the write request. For example, if the object metadata indicates that the AES-256-ECB algorithm is used and the tenant associated key ID is K123, then the algorithm identifier field in the request context is filled with 0x01 and the key identifier field is filled with K123.

[0042] Furthermore, the received plaintext data is encrypted on the network encryption / decryption data plane according to the aforementioned request context, and the resulting ciphertext data is the processing result. The encryption process is completed in the data plane hardware acceleration engine and does not consume host CPU resources. For write requests, the encrypted ciphertext data is encapsulated into a network packet and returned by the computation processing entity along the network path to the access coordination entity.

[0043] Finally, after receiving the encrypted data, the access coordination entity sends the encrypted data to the target storage service entity for persistence, based on the storage organization strategy carried in the original write request. The address of the target storage service entity is determined during the S1 resolution phase and can be an object storage node, a distributed file system data node, or a block storage backend. After receiving the write confirmation from the storage service entity, the access coordination entity returns a write success response to the business initiating entity. Through the above process, large-scale encrypted computation in the write path is successfully offloaded to the on-network data plane, while encrypted persistence remains under the unified control of the access coordination entity.

[0044] According to another aspect of this application, the decryption and unloading process for a read request is as follows:

[0045] When a cloud storage access request is a read request, this application executes a decryption and unloading process that is symmetrical to but in the opposite direction to a write request. Specifically, the data to be processed in a read request does not originate directly from the business initiating entity, but rather requires the access coordination entity to first obtain the encrypted data from the storage service entity. During the S1 parsing phase, the access coordination entity determines the address of the target storage service entity storing the encrypted data based on the object metadata. Subsequently, the access coordination entity initiates a read operation to that storage service entity to obtain the complete encrypted data block or encrypted fragment.

[0046] According to one aspect of this application, after acquiring the encrypted data, the access coordination entity sends it as data to be processed to the computation processing entity. Simultaneously, the control plane of the computation processing entity sets the operation mode in the request context to "decryption mode" based on the semantics of the read request. The control plane also extracts the algorithm identifier and key identifier from the security policy associated with the read request, ensuring that the algorithm and key used for decryption are completely consistent with those used for encryption during writing. For example, if the SM4-ECB algorithm and key identifier K456 are used during writing, the same algorithm identifier and key identifier must also be used in the decryption context of the read request.

[0047] Furthermore, the network encryption / decryption data plane performs decryption processing on the received ciphertext data according to the request context. The decryption engine decrypts the ciphertext blocks one by one according to the algorithm block length to recover the original plaintext data. The plaintext data obtained after decryption is the processing result data. The computation processing entity returns this plaintext data to the access coordination entity along the network path.

[0048] Finally, after receiving the plaintext data, the access coordination entity returns the plaintext data to the business initiating entity according to the response semantics of the read request. Before returning, the access coordination entity can perform an optional response data reassembly operation: if the original read request was split into multiple blocks for reading and decryption due to the large size of the object, these blocks need to be sequentially assembled into a complete object before being returned. Through the above process, the decryption calculation in the read path is offloaded from the host CPU to the on-network data plane, while maintaining the business logic that the decryption result is uniformly returned by the access coordination entity.

[0049] According to another aspect of this application, the process for determining the extended fields of the request context and the key is as follows:

[0050] In this application, the request context is a core data structure connecting the access coordination entity and the control plane and data plane of the computation processing entity. In addition to the operation mode (encryption / decryption / bypass), the request context also contains several extended fields for fine-grained control of data processing behavior. Specifically, the request context includes at least one or more of the following fields: request number, request type, algorithm identifier, key identifier, data length, and data block number.

[0051] The request number is a globally unique or request-level unique identifier, assigned by the access coordination entity when parsing the request and passed to the control plane. This number is carried in the header of each datagram, enabling the on-net encryption / decryption data plane to associate the datagram with the pre-configured request context. The request type field distinguishes between write requests, read requests, and bypass requests, and is used to assist the data plane in performing consistency checks: for example, if the request type is a write request but the context operation mode is decryption, an exception is triggered.

[0052] The algorithm identifier field specifies the encryption or decryption algorithm used in the current request. For example, 0x01 can represent AES-256-ECB, 0x02 can represent SM4-ECB, and 0x03 can represent AES-256-GCM, etc. This solution does not limit the specific algorithm; only a unified encoding needs to be agreed upon between the control plane and the data plane. The key identifier field is used to index or retrieve the corresponding key material. The key identifier can be an integer value pointing to a key slot in the key management service, or it can be a string representing a key name.

[0053] The data length field identifies the size of the data to be processed, in bytes. The data plane can use this length to determine whether to receive a complete data block and to verify whether the length of the processing result meets expectations after processing. The data block number field is used in block-splitting scenarios to identify the sequence number of the current data block within the complete object. For large objects, the access coordination entity can split them into multiple data blocks and send them to the computation processing entity for processing. Each data block carries a different data block number but shares the same request number.

[0054] According to a further improvement of this embodiment, the network encryption / decryption data plane determines the algorithm and key used for encryption or decryption based on the algorithm identifier and key identifier carried in the request context. Specifically, the data plane maintains an algorithm lookup table that maps algorithm identifiers to corresponding hardware acceleration engine entry points; it also maintains a key cache table that maps key identifiers to locally stored key materials. When the data plane processes a message, it can quickly obtain the algorithm and key by looking up the table, eliminating the need for each message to carry the complete algorithm name and key content, thereby reducing message overhead.

[0055] According to another aspect of this application, the collaborative mechanism for separating the control plane and the data plane is as follows:

[0056] In this application, the control plane of the computation processing entity is separated from the on-network encryption / decryption data plane. Specifically, the control plane of the computation processing entity is responsible for handling low-frequency, stateful, and policy-based tasks, including: request identification: parsing the request type and parameters from the control messages sent by the access coordination entity; operation mode selection: determining the encryption or decryption mode based on write or read requests; algorithm selection: determining whether to use AES, SM4, or other algorithms based on security policies or object metadata; key loading: obtaining key identifiers from the key management service or directly obtaining key materials and loading them into a key cache accessible to the data plane; request context generation: assembling the above information into a context data structure; and state management: monitoring the processing progress, collection completion status, or abnormal status of the data plane.

[0057] In contrast, the network encryption / decryption data plane is responsible for handling high-frequency, continuous, and throughput-sensitive data operations. Specific tasks include: Data reception: receiving data packets from the access coordination entity via the network port, extracting the request number and payload; Encryption processing: encrypting the plaintext using the encryption engine based on the request context; Decryption processing: decrypting the ciphertext using the decryption engine based on the request context; Outputting results: re-encapsulating the processed data into network packets and sending them back to the target address specified by the access coordination entity (i.e., the access coordination entity); Status feedback: reporting status information (such as processing success, byte count, error code, etc.) to the control plane upon completion of processing or detection of an anomaly.

[0058] According to one aspect of this application, communication between the control plane and the data plane is implemented through register interfaces, message queues, shared memory, DMA descriptors, or dedicated control messages. For example, in a DPU-based implementation, the control plane runs on the ARM core of the DPU, while the data plane runs within the DPU's programmable hardware pipeline. The control plane sends context requests to the data plane through registers in the PCIe BAR space, and the data plane reports its status to the control plane by writing back to registers or sending interrupts. This separate architecture allows complex control logic to not block high-speed data paths, enabling the data plane to process network traffic at line speed, while the control plane can flexibly respond to policy changes and abnormal situations.

[0059] According to another aspect of this application, the bypass processing procedure is as follows:

[0060] In this application, not all cloud storage access requests require encryption or decryption. For example, when an object is marked as unencrypted (such as publicly available static resources or data already encrypted by the client), or when the access request itself is merely a metadata query rather than data transmission, a bypass processing mode can be used. The bypass processing is triggered when the access coordination entity determines that the current cloud storage access request does not require encryption or decryption.

[0061] Specifically, after the access coordination entity completes request parsing, if the security policy or object attributes indicate that encryption protection is not required, the access coordination entity marks the cloud storage access request as a bypass request. This marking can be achieved by setting a bypass flag in the internal data structure. Subsequently, during the interaction between the access coordination entity and the computing processing entity's control plane, the control plane sets the operation mode in the request context to bypass mode based on this bypass flag.

[0062] According to a further improvement of this embodiment, when the operation mode is bypass mode, the algorithm identifier and key identifier fields in the request context can be left blank or set to invalid values. After receiving the request context in bypass mode, the behavior of the data plane in the network encryption / decryption process is fundamentally different from that in encryption / decryption mode: the data plane does not change the data content, that is, it does not perform any cryptographic operations on the payload; the data plane only performs reception and forwarding processing, that is, it receives data packets from the network port, keeps the payload intact, and then forwards the packets according to the return target address (still the access coordination entity) in the request context.

[0063] In one optional implementation, the data plane in bypass mode still performs basic message integrity checks (such as length verification and request number matching), but does not affect the data payload. After receiving the unmodified data returned from the computation processing entity, the access coordination entity performs subsequent operations based on the type of the original request: for write bypass requests, plaintext data is sent directly to the storage service entity; for read bypass requests, data obtained from the storage service entity is returned directly to the service initiating entity. Through this bypass process, this solution seamlessly supports cloud storage access that does not require encryption protection, avoiding unnecessary data migration and computational overhead.

[0064] According to another aspect of this application, the exception handling process is as follows:

[0065] This application fully considers various abnormal situations that may occur during network encryption and decryption processing and designs corresponding abnormal handling procedures. Abnormal detection is performed by the network encryption / decryption data plane. Specifically, when the data plane is processing data packets or matching request contexts, if it detects one or more of the following situations, it is determined to be an abnormality: missing request context (i.e., the request number carried in the data packet cannot be found in the context table), unrecognizable operation mode (the value of the operation mode field in the context exceeds the definition range of encryption / decryption / bypass), invalid algorithm identifier (the algorithm identifier is not registered in the data plane algorithm lookup table), invalid key identifier (the key identifier cannot find the corresponding key in the key cache), data length does not meet the encryption block requirements (e.g., the data length in encryption mode is not an integer multiple of the block length and is not the last block), data processing timeout (the data plane waits for subsequent blocks for more than a preset time window), and unavailable output path (the network port returned to the access coordination entity is faulty or congested).

[0066] When any of the above-mentioned anomalies are detected, the data plane returns an anomaly status to the control plane of the computation processing entity. The anomaly status information includes at least: request number, anomaly type code, and additional diagnostic data (such as actual data length, invalid key identifier value, etc.). Upon receiving the anomaly status, the control plane can perform one or more processing operations based on the anomaly type.

[0067] For example, for exceptions such as missing request context or unrecognizable operation mode, the control plane can discard the exception data and return an error message to the access coordination entity. For exceptions such as invalid algorithm identifier or key identifier, the control plane can attempt to retrieve the latest algorithm configuration or key material from the key management service and then reissue the request context. For exceptions such as data length not meeting the requirements of encrypted blocks, the control plane can switch the request to the host CPU software processing path, where the software performs padding or special processing. For exceptions such as data processing timeout or unavailable output path, the control plane can notify the access coordination entity to retry or degrade the process (e.g., reschedule the request to another computation processing entity).

[0068] According to a preferred embodiment of this application, the control plane can also record anomaly logs for subsequent auditing and fault diagnosis. Through the aforementioned anomaly handling mechanism, this solution can prevent erroneous data from continuing to enter the storage service entity or returning to the business initiating entity, thereby improving the reliability and robustness of the cloud storage encryption offloading process.

[0069] The cloud storage encryption offloading method based on on-network computing proposed in this application completely offloads encryption and decryption processing from the host CPU software path to the adjacent network data plane of the computing processing entity, while maintaining unified control of the access coordination entity over the writing of persistent organization and the return of read responses. Each step is tightly logically linked through key data structures such as request number and request context, ensuring the correctness and traceability of data processing. This method is suitable for cloud storage scenarios with high bandwidth and low latency requirements, effectively improving overall system throughput and reducing end-to-end latency.

[0070] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention.

Claims

1. A cloud storage encryption offloading method based on on-network computing, characterized in that, include: The access coordination entity receives cloud storage access requests from the business initiating entity, parses the cloud storage access requests to determine the data to be processed, the target storage service entity, and the business initiating entity; The access coordination entity sends the data to be processed to the computing processing entity. The computing processing entity has an on-network encryption and decryption data plane with a nearby network path, and the control plane of the computing processing entity generates a request context based on the cloud storage access request. In the network encryption / decryption data plane, encryption or decryption processing is performed on the data to be processed according to the request context to obtain the processing result data. The computing processing entity then returns the processing result data to the access coordination entity along the network path. Depending on the type of cloud storage access request, the access coordination entity will send the encrypted ciphertext data to the target storage service entity for persistence, or return the decrypted plaintext data to the business initiating entity.

2. The method according to claim 1, characterized in that, When a cloud storage access request is a write request, the data to be processed is plaintext data, the operation mode in the request context is encrypted mode, and the processing result data is ciphertext data; the access coordination entity sends the ciphertext data to the target storage service entity to complete the persistence.

3. The method according to claim 1, characterized in that, When the cloud storage access request is a read request, the data to be processed is encrypted data obtained by the access coordination entity from the storage service entity, the operation mode in the request context is decryption mode, and the processing result data is plaintext data. The access coordination entity returns plaintext data to the business initiating entity.

4. The method according to claim 1, characterized in that, The request context also includes one or more of the following: request number, request type, algorithm identifier, key identifier, data length, and data block number; the encryption and decryption data plane determines the algorithm and key used for encryption or decryption based on the algorithm identifier and key identifier carried in the request context.

5. The method according to claim 1, characterized in that, The control plane of the computational processing entity is separated from the on-network encryption / decryption data plane: the control plane of the computational processing entity is responsible for request identification, operation mode selection, algorithm selection, key loading, request context generation, and state management; the on-network encryption / decryption data plane is responsible for data reception, encryption processing, decryption processing, result output, and state feedback.

6. The method according to claim 1, characterized in that, It also includes bypass processing steps: When cloud storage access requests do not require encryption or decryption, the access coordination entity marks the cloud storage access request as a bypass request. The control plane of the computation processing entity sets the operation mode in the request context to bypass mode. In the network encryption / decryption data plane, the data content is not changed according to the bypass mode; only receiving and forwarding processing is performed.

7. The method according to claim 1, characterized in that, It also includes exception handling steps: When one or more of the following conditions are detected in the network encryption / decryption data plane: missing request context, unrecognizable operation mode, invalid algorithm identifier, invalid key identifier, data length does not meet the encryption block requirements, data processing timeout, or unavailable output path, an abnormal status is returned to the control plane of the computation processing entity. The control plane of the computation processing entity performs one or more of the following operations based on the abnormal state: discarding abnormal data and returning an error message, re-issuing the request context, reloading the key, switching the corresponding request to the host CPU software processing path, or notifying the access coordination entity to retry or downgrade.

8. The method according to claim 1, characterized in that, The on-network encryption / decryption data plane within the computing processing entity is implemented by a smart network interface card (NIC), a data processing unit (DPU), an infrastructure processing unit (IPU), a field-programmable gate array (FPGA), or a programmable network data plane device.

9. The method according to claim 1, characterized in that, The access coordination entity is a proxy server, object storage gateway, distributed file system client, or cloud storage front-end coordination service; the storage service entity is an object storage node, distributed file system data node, or block storage back-end.

10. The method according to claim 1, characterized in that, Before the control plane of the computational processing entity generates the request context, a key loading step is also included: The control plane of the computation processing entity obtains the key identifier from the key management service and writes the key identifier into the request context; On the network encryption / decryption data plane, the corresponding key is indexed from the local key cache or external key management service based on the key identifier, and encryption or decryption processing is performed.

Images