Secure data movement

Abstract

The computer-implemented method includes receiving, by the transcoder, second encrypted data. The second encrypted data is obtained by encrypting data with a first key to create first encrypted data and then encrypting the first encrypted data with a second key to create second encrypted data. The method includes receiving the second key and decrypting the second encrypted data using the second key to obtain the first encrypted data. The method includes encrypting the first encrypted data using a third key to create third encrypted data and transmitting the third encrypted data to a destination node. The computer-implemented method includes receiving, by the transcoder, the second encrypted key. The second encrypted key is obtained by encrypting a key with the first key to create a first encrypted key and then encrypting the first encrypted key with the second key to create a second encrypted key.

Description

Technical Field

[0001] The present invention relates to data transfer using a storage system, and more particularly, to a secure transcoder for data transfer in a cloud storage system and a network.

Background Art

[0002] It is desirable to securely share data among various computer nodes. Secure data transfer is particularly beneficial when providing computing functions near the stored data. For example, each node can have a specific computing function (e.g., a database, an inference engine, etc.). In prior art approaches, access control has been used to restrict data sharing. Access control is not absolutely secure and can lead to data leakage. For example, there is a possibility that privileges are expanded or controls are misconfigured.

[0003] In other prior art approaches, the source node encrypts the stored data. In another approach, the source node may decrypt the data and send the data via a secure link for sharing. In yet another approach, the source node decrypts the data and the source node may share its decryption key with the destination node. In these applications, there are many opportunities for data leakage. In some applications, homomorphic encryption may be used to provide secure access to the data. However, homomorphic encryption is limited to situations where the destination node is permitted to perform computations on the data without accessing the plaintext of the data. Homomorphic encryption is limited in its usefulness due to its slow performance.

[0004] These various conventional approaches tend to require a high level of reliability from the destination node. Furthermore, these conventional approaches lack flexibility in function replacement. In this field, there is still a need for a way to securely share data and allow operations (e.g., computations near storage) while providing a high level of security with respect to the shared data, particularly including the ability to terminate sharing if the destination node misbehaves. [Overview of the Initiative]

[0005] A computer implementation method according to one embodiment includes receiving second encrypted data by a transcoder. The second encrypted data is obtained by first encrypting data with a first key to create first encrypted data, and then encrypting the first encrypted data with the second key to obtain second encrypted data. The method includes receiving the second key by a transcoder, and decrypting the second encrypted data using the second key by the transcoder to obtain the first encrypted data. The method also includes encrypting the first encrypted data using a third key by the transcoder to create third encrypted data, and transmitting the third encrypted data to a destination node by the transcoder. This computer implementation method has the advantage that the destination node can access and decrypt the data stored by the source node, as long as the transcoder permits the destination node. According to one embodiment, the computer implementation method may also include transmitting a third key to the destination node by a transcoder. The destination node decrypts the third encrypted data using the third key to obtain the first encrypted data. The destination node decrypts the first encrypted data using the first key and retrieves the data. An advantage of this embodiment is that the destination node can be provided with access to doubly encrypted data that it can decrypt, while the transcoder does not have access to the first key, thus preventing data leakage.

[0006] According to one embodiment, the computer implementation method may include the transcoder replacing the third key with a dummy key in order to terminate data sharing between the source node and the destination node. This embodiment has the advantage that access by the destination node to the stored data can be restricted even if the destination node holds a copy of the third key.

[0007] A system according to another embodiment includes a processor and logic integrated into the processor, logic executable by the processor, or logic integrated into the processor and executable by the processor. The logic is configured to perform the method described above.

[0008] A computer program product according to yet another embodiment includes one or more computer-readable storage media and program instructions stored together in one or more computer-readable storage media. The program instructions include program instructions for performing the method described above.

[0009] A computer implementation method according to one embodiment includes receiving a second encrypted key by a transcoder. The second encrypted key is obtained by first encrypting a key with a first key to create a first encrypted key, and then encrypting the first encrypted key with the second key to obtain a second encrypted key. The method includes receiving the second key by a transcoder, and decrypting the second encrypted key using the second key by the transcoder to obtain the first encrypted key. The method also includes encrypting the first encrypted key using a third key by the transcoder to create a third encrypted key, and transmitting the third encrypted key by the transcoder to a destination node. This embodiment can improve the efficiency of transcoding when transcoding keys is more efficient than transcoding relatively long data blocks.

[0010] According to one embodiment, the computer implementation method may include a transcoder transmitting a third key to a destination node. The destination node uses the third key to decrypt the third encrypted key and obtains the first encrypted key. The destination node uses the first key to decrypt the first encrypted key and obtains the key. An advantage of this embodiment is that the destination node can be provided with access to doubly encrypted data that it can decrypt, while the transcoder does not have access to the first key, thus preventing data leakage.

[0011] According to one embodiment, the computer implementation method may include the destination node using a key to decrypt data from the source node. This embodiment has the advantage of providing security through double encryption while avoiding the double encryption process for relatively long data blocks.

[0012] A computer program product according to yet another embodiment includes one or more computer-readable storage media and program instructions stored together in one or more computer-readable storage media. The program instructions include program instructions for performing the method described above.

[0013] Other aspects and approaches of the present invention will become apparent from the following detailed description. The following detailed description, in conjunction with the accompanying drawings, illustrates the principles of the present invention.

[0014] Next, preferred embodiments of the present invention will be described with reference to the following drawings, for illustrative purposes only. [Brief explanation of the drawing]

[0015] [Figure 1] This figure shows a cloud computing environment according to one embodiment of the present invention. [Figure 2] This figure shows an abstraction model layer according to one embodiment of the present invention. [Figure 3] This is a schematic architecture diagram relating to one embodiment of the present invention. [Figure 4] This is a schematic architecture diagram relating to one embodiment of the present invention. [Figure 5A] This is a schematic architecture diagram relating to one embodiment of the present invention. [Figure 5B] This is a schematic architecture diagram relating to one embodiment of the present invention. [Figure 5C] This is a schematic architecture diagram relating to one embodiment of the present invention. [Figure 5D] This is a schematic architecture diagram relating to one embodiment of the present invention. [Figure 6] This is a flowchart of a method relating to one embodiment of the present invention. [Figure 7] This is a flowchart of a method relating to one embodiment of the present invention. [Modes for carrying out the invention]

[0016] The following description is intended to illustrate the general principles of the present invention and is not intended to limit the claimed inventive concepts herein. Furthermore, certain features described herein can be used in combination with other described features in each of the various possible combinations and substitutions.

[0017] Unless otherwise specifically defined herein, all terms are to be interpreted in the broadest possible way, including the meaning as understood by those skilled in the art, the meaning as defined in dictionaries or specialized books, or both, and the meaning implied herein.

[0018] Also, in this specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Further, as used herein, the terms “comprises,” “comprising,” or both, define the presence of the stated features, integers, steps, operations, elements, or components or combinations thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof or combinations thereof.

[0019] In the following description, several embodiments are disclosed for sharing access to stored data between a source node and a destination node. In these embodiments, a transcoder is used to provide access to the data at the destination node without accessing the source private key for decrypting the stored data.

[0020] In a general embodiment, a computer-implemented method includes receiving, by a transcoder, second encrypted data. The second encrypted data is data encrypted with a first key to create first encrypted data, which is then encrypted with a second key to form the second encrypted data. The method includes receiving, by the transcoder, the second key and decrypting, by the transcoder, the second encrypted data using the second key to obtain the first encrypted data. The method also includes encrypting, by the transcoder, the first encrypted data using a third key to create third encrypted data and transmitting, by the transcoder, the third encrypted data to the destination node.

[0021] In another general embodiment, a system includes a processor and logic integrated with the processor, logic executable by the processor, or logic integrated with and executable by the processor. The logic is configured to perform the method described above.

[0022] In another general embodiment, a computer program product includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media. The program instructions include program instructions for performing the methods described above.

[0023] In a general embodiment, a computer-implemented method includes receiving, by a transcoder, a second encrypted key. The second encrypted key is obtained by encrypting a key with a first key to create a first encrypted key and then encrypting the first encrypted key with a second key to obtain the second encrypted key. The method includes receiving, by the transcoder, a second key and decrypting, by the transcoder, the second encrypted key using the second key to obtain the first encrypted key. The method also includes encrypting, by the transcoder, the first encrypted key using a third key to create a third encrypted key and transmitting, by the transcoder, the third encrypted key to a destination node.

[0024] In another general embodiment, a computer program product includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media. The program instructions include program instructions for performing the methods described above.

[0025] The present disclosure includes a detailed description regarding cloud computing, but it should be understood that the implementation forms of the teachings described herein are not limited to cloud computing environments. Rather, the embodiments of the present invention can be implemented in combination with any other type of computing environment known currently or developed later.

[0026] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and deployed with minimal administrative effort or interaction with service providers. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0027] The characteristics are as follows:

[0028] On-demand self-service: Cloud consumers can unilaterally prepare computing power, such as server time and network storage, automatically as needed, without requiring human interaction with service providers.

[0029] Broad network access: Computing power is available over the network and accessible through standard mechanisms. This facilitates utilization by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, PDAs).

[0030] Resource pooling: A provider's computing resources are pooled and delivered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated as needed. Generally, consumers have a sense of location independence because they do not manage or know the exact location of the resources provided. However, consumers may be able to identify the location at a higher level of abstraction (e.g., country, state, data center).

[0031] Rapid Elasticity: Computing power can be prepared quickly and flexibly, allowing it to scale out automatically and immediately, and to be quickly released and scale in immediately. To consumers, the computing power available for preparation often appears unlimited and can be purchased in any quantity at any time.

[0032] Service Measurement: Cloud systems leverage metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.

[0033] The service model is as follows:

[0034] Software as a Service (SaaS): The functionality offered to consumers is the ability to use the provider's applications running on a cloud infrastructure. These applications can be accessed from various client devices via thin client interfaces such as web browsers (e.g., webmail). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, except for configuring a limited number of user-specific applications.

[0035] Platform as a Service (PaaS): The functionality offered to consumers is the ability to deploy applications they have created or acquired to cloud infrastructure using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, and storage, but they can control the deployed applications and, in some cases, the configuration of their hosting environment.

[0036] Infrastructure as a Service (IaaS): The functionality provided to consumers is the provision of processors, storage, networking, and other basic computing resources that enable consumers to deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they can control the operating system, storage, and deployed applications, and in some cases, partially control certain network components (e.g., host firewalls).

[0037] The deployment model is as follows:

[0038] Private Cloud: This cloud infrastructure is operated exclusively for a specific organization. This cloud infrastructure can be managed by that organization or a third party and can reside on-premises or off-premises.

[0039] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by the organization or a third party and can reside on-premises or off-premises.

[0040] Public Cloud: This cloud infrastructure is provided to a large number of people or large industry groups and is owned by organizations that sell cloud services.

[0041] Hybrid Cloud: This cloud infrastructure combines two or more cloud models (private, community, or public). While maintaining the unique entities of each model, they are bound together by standards or individual technologies to achieve data and application portability (e.g., cloud bursting for load balancing across clouds).

[0042] Cloud computing environments are service-oriented environments that emphasize statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is the infrastructure, which includes a network of interconnected nodes.

[0043] Here, Figure 1 shows an exemplary cloud computing environment 50. As shown in the figure, the cloud computing environment 50 includes one or more cloud computing nodes 10. Local computer devices used by cloud consumers (e.g., PDAs or mobile phones 54A, desktop computers 54B, laptop computers 54C, or automotive computer systems 54N, or a combination thereof) can communicate with these nodes. The nodes 10 can communicate with each other. The nodes 10 can be grouped physically or virtually (not shown) in one or more networks, such as the private, community, public, or hybrid clouds or a combination thereof. This allows the cloud computing environment 50 to provide infrastructure, platforms, or software as a service, or a combination thereof, and cloud consumers do not need to maintain resources for these on their local computer devices. Note that the types of computer devices 54A-N shown in Figure 1 are merely examples, and it should be understood that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network addressable connection (e.g., using a web browser) or both.

[0044] Here, Figure 2 shows the set of functional abstraction layers provided by the cloud computing environment 50 (Figure 1). It should be understood that the components, layers, and functions shown in Figure 2 are merely illustrative, and the embodiments of the present invention are not limited to these. As illustrated, the following layers and corresponding functions are provided.

[0045] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include a mainframe 61, a reduced instruction set computer (RISC) architecture-based server 62, server 63, blade server 64, storage 65, and a network and network components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0046] The virtualization layer 70 provides an abstraction layer. From this layer, virtual entities such as virtual servers 71, virtual storage 72, virtual networks 73 including virtual private networks, virtual applications and operating systems 74, and virtual clients 75 can be provided.

[0047] As an example, the management layer 80 can provide the following functions: Resource preparation 81 enables the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 enables cost tracking as resources are used within the cloud computing environment and billing or invoicing for the consumption of these resources. As an example, these resources may include licenses for application software. Security enables not only protection of data and other resources but also identification and verification of cloud consumers and tasks. The user portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 enables the allocation and management of cloud computing resources to ensure that requested service levels are met. Service Level Agreement (SLA) planning and execution 85 enables the pre-arrangement and procurement of cloud computing resources that are expected to be needed in the future in accordance with the SLA.

[0048] Workload Layer 90 provides examples of capabilities available in a cloud computing environment. Examples of workloads and capabilities available from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom education delivery 93, data analytics processing 94, transaction processing 95, and secure data movement 96.

[0049] Various embodiments of the present invention include sharing access to stored data between a source node and a destination node by using a transcoder to provide the destination node with access to the data without accessing the source secret key for decrypting the stored data. In a preferred embodiment, the stored data is encrypted by the source node with a first source key, and this encrypted data (e.g., first encrypted data) is further encrypted by the source node with a second source key to create doubly encrypted data (e.g., second encrypted data). The first source key is shared with the destination node, and the second source key is shared with a secure transcoder. The transcoder provides a third key and shares the third key with the destination node. The transcoder uses the second key to decrypt the doubly encrypted data and uses the third key to re-encrypt the data, which is now in a single-encrypted state, to create doubly encrypted data with the third key (e.g., third encrypted data). The transcoder shares the third key with the destination node. The destination node accesses the double-encrypted data (for example, data encrypted with a first key and then with a third key) via the transcoder. The double-encrypted data is stored in a data store for persistent data.

[0050] An advantage is that, in at least some embodiments of the present invention, the destination node can access and decode the data as long as the transcoder allows it to do so (for example, according to a sharing policy established between the source node and the transcoder). Furthermore, the transcoder does not access the plain text data, and the destination node will no longer be able to access the stored data if the sharing policy is changed.

[0051] In other approaches, the source node encrypts each chunk of data with a different chunk key (for example, each chunk of data is encrypted with a unique chunk key). The source node then encrypts each data chunk and transcodes each data chunk. This key-per-chunk approach can significantly reduce the encryption load on the transcoder.

[0052] At least some of the embodiments described herein are advantageously usable with symmetric encryption techniques, which can provide relatively high performance compared to relatively slow public-key encryption methods for transferring data between nodes in a system.

[0053] Figure 3 is a schematic architecture diagram showing various configurations. Architecture 300 can be implemented in various configurations according to a preferred embodiment of the present invention, particularly in any of the environments shown in Figures 1-2 and Figures 4-7. Of course, as will be understood by those skilled in the art by reading this specification, architecture 300 may include more or fewer elements than those specifically shown in Figure 3.

[0054] Architecture 300, in its schematic architecture, includes a source node 302, storage 304, and a destination node 306. Source node 302 includes a source node compute resource 308, a first key k1 (310), and a second key k2 (312). Source node 302 also includes a source node manager function 314, a source node k1 encryption / decryption function 316, and a source node k2 encryption / decryption function 318. As those skilled in the art will understand from reading this disclosure, the encryption / decryption functions described herein can be configured to encrypt or decrypt or both data using appropriate keys and any known encryption techniques. Source node 302 may include multiple first keys, multiple second keys, multiple first key sets, multiple second key sets, and so on.

[0055] Storage 304 may be a storage system, a solid-state drive (SSD), a hard disk, a tape drive, storage class memory, DRAM, persistent storage, or any type of storage known in the art, or any combination thereof.

[0056] Architecture 300 includes a secure transcoder 320. The secure transcoder 320 includes a secure transcoder manager function 322 and a secure key storage 324 for a second key k2 (312). The secure transcoder 320 may include a key generator 326 in at least some approaches. The secure transcoder 320 includes a third key k3 (328). The secure transcoder 320 includes a secure transcoder k2 encryption / decryption function 330 and a secure transcoder k3 encryption / decryption function 332.

[0057] In various approaches, the key generator 326 generates a third key k3(328). In some approaches, the third key k3(328) may be generated by the source node 302. In other approaches, the third key k3(328) may be generated by the destination node 306. In a preferred embodiment, the third key k3(328) is generated by either the key generator 326 or the source node 302 to avoid being a weak key or key reuse. In yet other approaches, as will be apparent to those skilled in the art upon reading this disclosure, the keys described herein may be generated or managed, or both, by a key generator or key manager (not shown) or both, known in the art.

[0058] The secure transcoder 320 may be designed to perform sharing operations. Each sharing operation is preferably defined by a separate policy. The transcoder may have multiple key storages or multiple secure transcoder encryption / decryption functions, or both. These additional policies (and associated components) provide additional security for each sharing policy (for example, each sharing policy may have a separate and unique third key, even if they may access the same data).

[0059] The secure transcoder 320 can be implemented in hardware, software, or any combination thereof. To achieve the desired security, the secure transcoder 320 protects the second key k2(312) from external access to the secure transcoder 320, preventing security weakening or loss due to data leakage.

[0060] The destination node 306 includes a destination node compute resource 334, key storage 336 for the first key k1 (310), and key storage 338 for the third key k3 (328). The destination node 306 includes a destination node manager function 340. The destination node 306 includes a destination node k1 encryption / decryption function 342 and a destination node k3 encryption / decryption function 344.

[0061] Exemplary implementations according to various embodiments of architecture 300 will be described with reference to the arrows and / or connecting lines in Figure 3. Source node 302 stores data in storage 304. As will be apparent to those skilled in the art upon reading this disclosure, the data used throughout this disclosure may include application data, metadata, keys, any other kind of information, or any combination thereof. Encryption may be indicated by the encryption notation "encrypt(key, data)" and decryption may be indicated by the decryption notation "decrypt(key, data)" as used throughout this disclosure. Source node 302 storing a unit of data indicated by "P" preferably encrypts the data P as C1=encrypt(k1,P) using the first key k1(310) by source node k1 encryption / decryption function 316. Furthermore, source node k2 encryption / decryption function 318 encrypts this obtained (C1) as C2=encrypt(k2,C1) using the second key k2(312). The encrypted data C2 is sent to storage 304 in operation 346. The stored data is encrypted with the combination of the first key k1 (310) and the second key k2 (312). In some approaches, data that does not require encryption for sharing may be sent directly to storage 304 in operation 348. In various approaches, storage 304 may have encryption / decryption functions (not shown) for performing further encryption for data storage in a manner that would be obvious to those skilled in the art by reading this disclosure.

[0062] Before sharing data, it is preferable that the source node 302, storage 304, destination node 306, and secure transcoder 320 authenticate each other to verify each other's identity. In various approaches, the identity of each component within the architecture 300 may be authenticated according to protocols known in the art. In some approaches, authentication may be performed as part of establishing a secure communication connection between the parties. In a preferred embodiment, all communication links are secure (e.g., encrypted). For example, the source node 302 may use a sharing policy to configure data sharing access with the destination node 306. The sharing policy may include policy information such as the set of data to share, the sharing period, the amount of data to share, other access rights, etc., or any combination thereof. The policy information may be transmitted in operation 350 between the source node manager function 314 and the secure transcoder manager function 322 (e.g., from the source node manager function 314 to the secure transcoder manager function 322). The secure transcoder manager function 322 may verify that the policy information is correct and that the policy is supported by the secure transcoder 320. Such verification may include, in operation 352, communicating with the destination node manager function 340 to confirm that the policy is supported by the destination node 306. Depending on whether the identity of each component has been verified and the policy information has been verified, the source node 302 may, in operation 354, send the second key k2(312) to the secure transcoder 320. The secure transcoder 320 stores a copy of the second key k2(312) in the secure key storage 324 for the second key k2(312).

[0063] In a preferred embodiment, neither the secure transcoder 320 nor the destination node 306 can access both the first key k1(310) and the second key k2(312). Without such access, neither the secure transcoder 320 nor the destination node 306 can decrypt the data in the storage 304 stored by the source node 302. In a preferred embodiment, the secure key storage 324 for the second key k2(312) is volatile, and in the event of a power outage, the secure transcoder 320 must re-authenticate the affected party to re-establish the sharing (or vice versa, the affected party must re-authenticate the secure transcoder 320). In the event of a power outage, the secure transcoder 320 also re-authenticates the key storage 338 for the third key k3(328) to re-establish the sharing (or vice versa, the key storage 338 re-authenticates the secure transcoder 320). The period for which the secure transcoder 320 stores the second key k2(312) in the secure key storage 324 for the second key k2(312) is determined by the sharing policy, as described above. In response to the termination of sharing as indicated by the sharing policy, the secure transcoder 320 shreds (e.g., deletes or otherwise destroys) the stored copy of the second key k2(312) in any way that would be obvious to anyone skilled in the art by reading this disclosure. Shredding the second key k2(312) is beneficial to the secure key storage 324 for the second key k2(312) in restricting access to the secure transcoder k2 encryption / decryption function 330 by the stored key information. By shredding in this way, leakage of the second key k2(312) is prevented.

[0064] The secure transcoder 320 may generate a third key k3(328) using the key generator 326 as part of setting up data sharing after policy validation. The third key k3(328) is sent to the destination node 306 in operation 356. The destination node 306 stores a copy of the third key k3(328) in the key storage 338 for the third key k3(328). Furthermore, as part of setting up data sharing after policy validation, the source node 302 sends the first key k1(310) to the destination node 306 in operation 358. The destination node 306 stores a copy of the first key k1(310) in the key storage 336 for the first key k1(310). In a preferred embodiment, both the key storage 336 for the first key k1(310) and the key storage 338 for the third key k3(328) are volatile. In one preferred approach, when sharing ends, the secure transcoder 320 removes the third key k3(328) and stops accepting requests for the shared data from the destination node 306. In another approach, the secure transcoder 320 replaces the third key k3(328) with a dummy key in any way that would be obvious to anyone skilled in the art by reading this disclosure, so that when the destination node 306 requests the shared data, it will either receive no data, unusable data, or both (for example, the destination node 306 cannot read the data even if it has only the first key k1(310), and even if it uses the third key, the destination node 306 will not receive data encrypted with k1). If the destination node 306 has write access to the shared data, the dummy key terminates all write access in a way that would be obvious to anyone skilled in the art by reading this disclosure.

[0065] In another approach, the secure transcoder 320 notifies the destination node 306 that sharing has ended. In response to the termination of sharing, the destination node 306 deletes the stored copies of the first key k1(310) and the third key k3(328). The sharing policy can be terminated in any way that would be obvious to a person skilled in the art from reading this disclosure, such as by sending a command from the source node 302 to the secure transcoder 320, storage 304, destination node 306, or a combination thereof.

[0066] In an exemplary implementation, the destination node 306 performs a read operation by requesting data from the secure transcoder 320 in operation 360. The destination node 306 cannot directly access the shared data from storage 304. This is because the shared data in storage 304 is encrypted using a second key k2(312) that is unavailable to the destination node 306. If the read request is permitted by the sharing policy, the secure transcoder 320 reads the data related to the read request from storage 304 in operation 362. The data related to the read request is encrypted as C2=encrypt(k2,C1) as described above. In operation 364, the data related to the read request is decrypted as C1=decrypt(k2,C2) by the secure transcoder k2 encryption / decryption function 330 using the second key k2(312) This related data (which at this point is encrypted only with the first key k1(310)) is encrypted in operation 366 by the secure transcoder k3 encryption / decryption function 332 using the third key k3(328). The related data before operation 366 is still encrypted as C1=encrypt(k1,P), and the first key k1(310) is unavailable to the secure transcoder 320. Therefore, the secure transcoder 320 cannot decrypt the data stored in storage 304 by the source node 302. The secure transcoder k3 encryption / decryption function 332 uses the third key k3(328) to encrypt this related data as C3=encrypt(k3,C1) (for example, the data is encrypted with both the first key k1(310) and the third key k3(328)). The encrypted data is sent to the destination node 306 in operation 360. The destination node 306 can decrypt this data using the third key k3(328) via the destination node k3 encryption / decryption function 344 as C1=decrypt(k3,C3) (for example, the related data is encrypted only with the first key k1(310) at this point).The destination node 306 can decrypt the data using the first key k1 (310) via the destination node k1 encryption / decryption function 342, with the result P=decrypt(k1,C1) (for example, the destination node 306 will be able to access the plaintext (clear) data).

[0067] In a preferred embodiment, the sharing period between the destination node 306 and the source node 302 using the secure transcoder 320 is terminated by stopping communication in operation 360 in accordance with the sharing policy information described herein. In various approaches, if the communication channel between the destination node 306 and the secure transcoder 320 remains open, the sharing period between the destination node 306 and the source node 302 is terminated by the secure transcoder 320 shredding the third key k3(328) or the second key k2(312) or both. In other approaches, the secure transcoder 320 may terminate the sharing period by replacing the third key k3(328) or the second key k2(312) or both with a dummy key of a type known in the art. By shredding or replacing the third key k3(328) or the second key k2(312) or both, additional security can be provided, for example, even if communication in operation 360 is left open due to an error or design flaw. A destination node attempting to perform a malicious operation will not receive usable data from the secure transcoder if the secure transcoder does not have the correct key to decrypt the encrypted data. As will be apparent to those skilled in the art upon reading this disclosure, the secure transcoder 320 may be required to renegotiate with the source node 302 or the destination node 306 or both in order to continue or resume the sharing period after shredding the key. This "key rotation" can provide additional security to the system without requiring all data stored in storage to be re-encrypted. For example, in conventional systems, if the transcoder loses a key, one approach is to re-encrypt all data in storage, which can take a relatively long time compared to the renegotiation process described above.

[0068] Before saving the data unit P, the destination node 306 encrypts the data P as C1=encrypt(k1,P) using the first key k1(310) by the destination node k1 encryption / decryption function 342. The destination node 306 further encrypts this resulting C1 as C3=encrypt(k3,C1) using the third key k3(328) by the destination node k3 encryption / decryption function 344. A write request for the data (C2) is sent to the secure transcoder 320 in operation 360. If the write request is permitted by the sharing policy, the secure transcoder 320 accepts the write request. As described above, the data is encrypted as C3=encrypt(k3,C1). The written data is decrypted as C1=decrypt(k3,C3) using the third key k3(328) by the secure transcoder k3 encryption / decryption function 332. This write data is sent to the secure transcoder k2 encryption / decryption function 330 in operation 366. The write data in operation 366 is still encrypted as C1=encrypt(k1,P). The first key k1(310) is not available to the secure transcoder 320. Therefore, the secure transcoder 320 cannot decrypt the write data stored by the destination node 306. The secure transcoder k2 encryption / decryption function 330 further encrypts this write data as C2=encrypt(k2,C1) using the second key k2(312). This encrypted data (for example, with the first key k1(310) and the second key k2(312)) is sent to storage 304 in operation 362. Source node 302 can decrypt the data as C1=decrypt(k2,C2) and P=decrypt(k1,C2) using appropriate keys that will be apparent to those skilled in the art from the content of this disclosure, via source node k2 encryption / decryption function 318 and source node k1 encryption / decryption function 316, respectively.

[0069] In one alternative approach, the data may be encrypted by source node 302 with a fourth key (not shown), which may be encrypted according to the various embodiments described above. Thus, the fourth key is the data to be encrypted. In this approach, the key is transcoded instead of the data, resulting in relatively efficient transcoding. For example, the data block length may be 4kB and the key length 32B. Transcoding such a key is approximately 128 times more efficient than transcoding the data blocks. In this approach, after the encryption of the fourth key, the data (e.g., the encrypted key) may be sent to storage 304 in operation 346, thereby bypassing source node k1 encryption / decryption function 316 and source node k2 encryption / decryption function 318. When transcoding, the data (e.g., the encrypted key) may be sent to the destination node in operation 368, thereby bypassing secure transcoder k2 encryption / decryption function 330 and secure transcoder k3 encryption / decryption function 332.

[0070] In other approaches, encryption may be performed using additional information that needs to be separated from the secure transcoder 320. For example, an initialization vector (IV) may be used for encryption. As will be understood by those skilled in the art, the IV can point to any number used only once, together with a secret key for data encryption. By using the IV for encryption with the first key, the IV can be avoided from being exposed to encryption with the second key. As will be apparent to those skilled in the art by reading this disclosure, the IV information can be advantageously used to break translation symmetry to provide additional security depending on the implementation of the IV. For example, in AES-XTS, the IV is an address that breaks address symmetry. If the IV is based on data content, translation symmetry is preserved. In a preferred embodiment, the IV information is shared with the destination node 306 but not with the secure transcoder 320. The IV may be used for encryption with the second key, regardless of whether the IV is used for encryption with the first key, without compromising the security of the architecture described herein. As will be apparent to those skilled in the art from reading this disclosure, if the secure transcoder 320 needs to know the IV for encryption with a second key, the information for deriving the IV may be part of negotiations to establish a secure connection between the secure transcoder 320 and the source node 302.

[0071] In a secure deduplication system that uses a key for each chunk, a fingerprint may be computed for each chunk of plaintext data, and the data chunks are encrypted with a chunk-specific key (for example, each data chunk is encrypted with a unique data chunk key, such as the fourth key described above). The fingerprint is encrypted with a fifth key (for example, a fingerprint key) to prevent the deduplication storage system from associating a particular fingerprint with a particular plaintext. For transcoding according to the various embodiments described herein, the data chunk key may be data encrypted by the source node with a first key and a second key. The first and second keys for encrypting the fingerprint may be different from the first and second keys for encrypting the data chunk key. Different datasets of fingerprints and chunk keys are securely transcoded for use at the destination node. Generally, throughout this disclosure, there may be multiple first keys and multiple second keys for transcoding data, keys, metadata, etc., that are securely shared between source and destination nodes using a secure transcoder.

[0072] Another approach involves a secure deduplication system where a second set of keys belongs to a key group, which includes a first key, a fingerprint key, and a dedup key. In this approach, the storage system may store the deduplicated data in a way that prevents decryption with the dedup key. The data may be transcoded from one of the second keys to the dedup key of the key group, or from the dedup key of the key group to one of the second keys, using a secure transcoder, such as one configured to perform at least some of the various embodiments detailed above.

[0073] In another embodiment, the key group may include a set of first keys instead of a single common first key. As will be apparent to those skilled in the art upon reading this disclosure, in this approach it is preferable that there be a first key for each second key and deduplication key.

[0074] Figure 4 is a schematic architecture diagram showing various configurations. Architecture 400 can be implemented in various configurations according to a preferred embodiment of the present invention, particularly in any of the environments shown in Figures 1-3 and 5A-7. Of course, as will be understood by those skilled in the art by reading this specification, Architecture 400 may include more or fewer elements than those specifically shown in Figure 4.

[0075] Architecture 400 is a variation of at least some aspects of the embodiment shown in Figure 3. Therefore, common features are given common numbering. Architecture 400, in its schematic architecture, includes a source node 302, storage 304, and a destination node 306. Source node 302 includes a source node compute resource 308, a first key k1 (310), and a second key k2 (312). Source node 302 also includes a source node manager function 314, a source node k1 encryption / decryption function 316, and a source node k2 encryption / decryption function 318. As will be understood by those skilled in the art by reading this disclosure, the encryption / decryption functions described herein can encrypt or decrypt data, or both, using the associated keys.

[0076] Architecture 400 includes a secure transcoder 320. The secure transcoder 320 includes a secure transcoder manager function 322 and a secure key storage 324 for a second key k2(312). The secure transcoder 320 may include a key generator 326 in at least some approaches. The secure transcoder 320 includes a third key k3(328). In various approaches, the key generator 326 generates the third key k3(328). In other approaches, any of the keys described herein may be generated or managed, or both, by a key generator or key manager (not shown) or both, known in the art. The secure transcoder 320 includes a secure transcoder k2 encryption / decryption function 330 and a secure transcoder k3 encryption / decryption function 332.

[0077] The secure transcoder 320 may be designed to perform shared operations. Each shared operation is preferably defined by a separate policy. The transcoder may have multiple key storages or multiple secure transcoder encryption / decryption functions, or both. These additional policies (and associated components) provide additional security for each shared policy (for example, each shared policy may have a separate and unique third key, even if they may access the same data).

[0078] The destination node 306 includes a destination node compute resource 334, key storage 336 for the first key k1 (310), and key storage 338 for the third key k3 (328). The destination node 306 includes a destination node manager function 340. The destination node 306 includes a destination node k1 encryption / decryption function 342 and a destination node k3 encryption / decryption function 344.

[0079] The architecture 400 in Figure 4 shows an exemplary implementation of a system in which double encryption of data is not performed (for example, as illustrated and described in the preferred embodiment of Figure 3). Here, the source node 302 stores data in the storage 304 without encryption with the first key k1(310) and without encryption with the second key k2(312). The secure transcoder 320 does not communicate with the storage 304. On the other hand, the source node 302 reads all data from the storage 304. The source node 302 generates the first key k1(310) and the second key k2(312). The secure transcoder manager function 322 passes all read and write requests to the source node manager function 314 of the source node 302.

[0080] In the case of a read request, the source node k1 encryption / decryption function 316 encrypts the data using the first key k1 (310) and obtains the first encrypted data. The source node k2 encryption / decryption function 318 encrypts this encrypted data using the second key k2 (312) and obtains the second encrypted data. The second encrypted data is sent to the secure transcoder manager function 322 in operation 350, and the second encrypted data is transcoded as detailed with reference to Figure 3. In the case of a write request, the data is decrypted as described herein and written back to storage 304 as plaintext.

[0081] For customers who wish to transition to double-encrypting all data in various approaches, write requests may be written in a double-encrypted state. In this case, metadata is stored in the block and file system by any method known in the art to indicate the encryption status of the data. All new data is double-protected (e.g., double-encrypted), and all "old" data is double-protected after being fully accessed. In this way, the system can track the state of the files and have a background task access the remaining data for files that have reached the selected protection level, thereby ensuring that the remaining data is fully protected (e.g., double-encrypted).

[0082] In another embodiment, if the secure transcoder 320 can access the storage 304 (as shown in Figure 3), the secure transcoder 320 may be modified to refer to file metadata to determine the encryption status of the file. If the file is protected (e.g., double-encrypted), the secure transcoder 320 may read the file directly (as shown in Figure 3) as described above, or, if not, may request the data from the source node manager function 314. The security associated with this embodiment is less desirable than the security in Figure 3 described above (e.g., the secure transcoder 320 requests all data from the source node manager function 314). Allowing unencrypted data on the storage 304 is most secure if the destination node 306 cannot access the stored data.

[0083] Figures 5A to 5D are schematic architectural diagrams according to various configurations. Architecture 500 can be implemented in various configurations according to a preferred embodiment of the present invention, particularly in any of the environments shown in Figures 1 to 3 and Figures 6 to 7. Of course, as will be understood by those skilled in the art by reading this specification, Architecture 500 may include more or fewer elements than those specifically described in Figures 5A to 5D.

[0084] Each architecture 500 includes a source node 302 (as described with reference to Figures 3-4), storage 304 (as described with reference to Figures 3-4), a destination node 306 (as described with reference to Figures 3-4), and a secure transcoder 320 (as described with reference to Figures 3-4). As shown, the secure transcoder 320 may be located anywhere in the system. For example, as shown in Figure 5A, the secure transcoder 320 may be part of the source node 302. This configuration may be located in a central processing unit (CPU) complex, an I / O hub, a bridge, the CPU itself, or a network interface card (e.g., a smart NIC).

[0085] As shown in Figure 5B, the secure transcoder 320 may be located within a storage network connected to the source node 302, storage 304, and destination node 306. This configuration may be implemented in a switch, edge application, gateway, or any other location.

[0086] As shown in Figure 5C, the secure transcoder 320 may be part of the storage 304. The secure transcoder 320 may also be directly integrated into the storage, storage controller, host bus adapter, smart NIC, etc.

[0087] As shown in Figure 5D, the secure transcoder 320 may be part of the destination node 306. This configuration may be located in the CPU complex, I / O hub, bridge, CPU itself, smart NIC, etc.

[0088] In various approaches, it is beneficial to have a secure transcoder at each of the multiple locations (e.g., all four locations shown in Figures 5A-5D, etc.) to enable setting up a share using the optimal transcoding location for a particular operation. For example, transcoding at the source node is beneficial for storage directly connected to the source. In another example, as will be understood by those skilled in the art, transcoding at storage is beneficial for scaling and network utilization. In some cases, the destination node of a first share may be the source node of a second share, and it is advantageous to have transcoding capabilities at each source node and each destination node. From a security standpoint, using the transcoding capabilities described herein at the destination node as the transcoding location for a share shown in Figure 3 may be undesirable (even if the destination node has transcoding capabilities). In this case, both the first and second keys would reside at the destination node. As will be apparent to those skilled in the art from reading this disclosure, if all nodes (e.g., source node, storage, and destination node) each have transcoding capabilities, in a preferred embodiment, to obtain the strongest security, the protocol for accessing the data does not utilize the transcoder at the destination node.

[0089] To achieve robust security, it is beneficial to treat the first and second keys as a data isolation pair. For example, a set of information encrypted with the first key should be identical to a set of information encrypted with the second key. If multiple second keys use a single common first key, data can be moved across key boundaries, potentially exposing the data to leakage.

[0090] In a preferred embodiment, all the arrows shown in Figures 3 to 5D, and any communication between the components described herein, may include additional protocols for communication encryption known in the art. For example, as will be apparent to those skilled in the art by reading this disclosure, protocols such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS), which are communication encryption protocols, may be used to transfer keys between the source node and the destination node, between the source node and the secure transcoder, and between the secure transcoder and the destination node, etc.

[0091] Next, Figure 6 is a flowchart of Method 600 according to one embodiment. Method 600 can be carried out in various ways in any of the environments shown in Figures 1 to 5D and Figure 7 in particular, according to a preferred embodiment of the present invention. Of course, as will be understood by those skilled in the art who read this specification, Method 600 may include more or fewer operations than those specifically described in Figure 6.

[0092] Each step of Method 600 may be performed by any suitable component in the operating environment. For example, in various embodiments, Method 600 may be performed in part or in whole by a computer or any other device having one or more processors. One or more steps of Method 600 may be performed by utilizing a processor (e.g., a processing circuit, chip or module or combination thereof implemented in hardware or software or both, preferably having at least one hardware component) in any device. Examples of processors, but not limited to, include central processing units (CPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and combinations thereof, as well as any other suitable computing device known in the art.

[0093] As shown in Figure 6, method 600 includes operation 602, which includes receiving second encrypted data by a transcoder. The second encrypted data is obtained by first encrypting the data with a first key to create first encrypted data, and then encrypting this with a second key to obtain second encrypted data. In a preferred embodiment, the encryption of the data into first encrypted data and then the encryption of the first encrypted data into second encrypted data are performed at the source node. The source node includes a first key and a second key.

[0094] In one approach, the second encrypted data is received at least partially based on a data request from the transcoder to storage. In response to receiving a data request from the destination node, the transcoder may send the data request directly to storage. In one approach, storage may send the second encrypted data directly to the transcoder in response to the data request. For example, before the source node stores the second encrypted data in storage, the source node may encrypt the data with the first key to create the first encrypted data, and then encrypt this with the second key to create the second encrypted data. Storage may send the second encrypted data to the transcoder in response to a data request from the transcoder.

[0095] In an alternative approach, the second encrypted data is received at least partially based on a data request from the transcoder to the source node. In response to receiving a data request from the destination node, the transcoder may send a data request to the source node. The source node may store the second encrypted data in storage. The source node may then send the second encrypted data (which it previously stored in storage) back to the transcoder.

[0096] In yet another approach, the source node may store the data in storage without encryption. In response to receiving a data request from the transcoder, the source node may retrieve the unencrypted data from storage, encrypt this unencrypted data with a first key to create first encrypted data, encrypt this first encrypted data with a second key to create second encrypted data, and send this to the transcoder in response to a data request from the transcoder to the source node.

[0097] In various embodiments, the second encrypted data is received by the transcoder from storage, a source node, etc., based on a data request from at least one destination node. There may be any number of destination nodes that request data from the source node via the transcoder. In some approaches, the transcoder may receive the second encrypted data in response to a data request from a destination node, according to sharing policy information between the source node, destination node, storage, transcoder, etc. The sharing policy information may include which data can be shared between which entities, the length of the sharing period between entities, the number of operations associated with the sharing period between entities, and the amount of data that can be shared between entities per sharing period. In various approaches, the sharing policy information determines when the sharing period ends. In various embodiments, the sharing period can end according to the policy in response to at least one key being shredded, in response to a request from the source node to end the sharing period, in response to a power-off event, in response to any other trigger event, etc., or in response to a combination thereof.

[0098] In at least some approaches, the source node stores data in storage. The data may be unencrypted data, second encrypted data, or data encrypted with another key (e.g., data encrypted with a key other than the first or second key before encryption with the first key and then the second key). In a preferred embodiment, the source node includes the first key and the second key. In some approaches, the encryption of data to create the first encrypted data, and then the encryption of the first encrypted data to create the second encrypted data, may be performed by at least one encryption / decryption function of the source node. In other approaches, as will be understood by those skilled in the art from the content of this disclosure, each key may be associated with a separate encryption / decryption function located on the source node.

[0099] Operation 604 includes the transcoder receiving a second key. In various approaches, the second key is received from the source node. In various approaches, the source node sends a copy of the second key to the transcoder, which securely stores the second key for a period, number of operations, etc., as defined by the sharing policy information. In at least some embodiments, in response to the termination of the sharing period (e.g., due to a decision by the sharing policy or a request from the source node), the transcoder may shred the second key, replace the second key with a dummy key, or both, in a manner obvious to those skilled in the art by reading this disclosure. The dummy key may be of any type known in the art.

[0100] In other approaches, the second key may be received from a key manager. The key manager may be coupled to the source node, destination node, or any other component or combination in the network to provide, generate, and manage keys for sharing data between the source node and the destination node.

[0101] Operation 606 includes the transcoder decrypting the second encrypted data using the second key to obtain the first encrypted data. As described above, the second encrypted data is obtained by first encrypting the data with the first key to create the first encrypted data, and then encrypting this with the second key to obtain the second encrypted data. According to operation 606, the transcoder may obtain the first encrypted data using an encryption / decryption function in the transcoder and the second key (which in some approaches is sent from the source node). Preferably, the transcoder does not have access to the first key (for example, to decrypt the first encrypted data and obtain the data) and cannot obtain the plaintext data (or the original data in a form encrypted with another key).

[0102] Operation 608 includes the transcoder encrypting the first encrypted data using a third key to create the third encrypted data. The first encrypted data (for example, encrypted only with the first key) may be encrypted with a new third key by an encryption / decryption function on the transcoder to create the third encrypted data. The encryption / decryption function may be the same as the encryption / decryption function of operation 606, or it may be different (for example, a separate function dedicated to the third key). In at least some approaches, the third key may be generated by the transcoder using a key generator on the transcoder. In other approaches, arbitrary keys may be generated or managed, or both, by a key manager or key generator, or both, coupled to the source node, transcoder, destination node, etc.

[0103] In various approaches, Method 600 includes the transcoder sending a third key to a destination node. In a preferred approach, the destination node receiving the third key is the destination node that initiated the data request. In various approaches, the transcoder sends a copy of the third key to the destination node, and the destination node securely stores the data for a period of time, number of operations, etc., in accordance with the definition of the sharing policy information, or in any way that is obvious to a person skilled in the art by reading this disclosure, or both. In a preferred embodiment, in response to the termination of the sharing period (e.g., by a decision by the sharing policy or a request from the source node), the transcoder shreds the third key, replaces the third key with a dummy key, or both, in any way that is obvious to a person skilled in the art by reading this disclosure, in order to terminate data sharing between the source node and the destination node. The dummy key may be of any type known in the art.

[0104] In other approaches, the third key may be sent from the key manager to the destination node. The key manager may be coupled to the source node, destination node, or any other component or combination in the network to provide, generate, and manage keys for sharing data between the source node and the destination node.

[0105] Operation 610 includes the transcoder sending third encrypted data to the destination node. The third encrypted data is obtained by encrypting the first encrypted data (e.g., data encrypted with the first key) with the third key, as described above. In various approaches, the destination node receives the first key directly from the source node. In various approaches, the destination node is configured to decrypt the third encrypted data using the third key and obtain the first encrypted data by an encryption / decryption function on the destination node. The destination node is configured to decrypt the first encrypted data using the first key and obtain the data by an encryption / decryption function on the destination node (which may be the same as or different from the encryption / decryption function used to decrypt the third encrypted data and obtain the first encrypted data). As described above, the data may be plaintext data, unencrypted data, plaintext data, or data in a form encrypted with another key.

[0106] In one embodiment, data (e.g., unencrypted data) comprises multiple data chunks, each data chunk being encrypted with a fourth key. The fourth key may be encrypted with the first key to create a first encrypted fourth key, which may then be encrypted with the second key to create a second encrypted fourth key. As will be apparent to those skilled in the art by reading this disclosure, in at least some approaches, each data chunk may be associated with a different fourth key. In the embodiments described above, the transcoder may receive the second encrypted fourth key and the second key in the same manner as described in operations 602 and 604, respectively. The transcoder may decrypt the second encrypted fourth key using the second key to obtain the first encrypted fourth key (e.g., encrypted only with the first key at this point) in the same manner as described in operation 606. The transcoder may encrypt the first encrypted fourth key using the third key to create the third encrypted fourth key in the same manner as described in operation 608. The transcoder may send a third key and a third encryption fourth key (for example, the fourth key encrypted with the first key to obtain the first encryption fourth key, and this encrypted with the third key to obtain the third encryption fourth key) to the destination node (for example, similar to operation 610 described in method 600). The destination node may then be configured to decrypt the third encryption fourth key using the third key (received from the transcoder or key manager through various approaches) to obtain the first encryption fourth key. The destination node may then decrypt the first encryption fourth key using the first key received from the source node or key manager through various approaches to obtain the fourth key. The fourth key can then be used to decrypt the data chunk encrypted with the fourth key and sent to the destination node. If the key length is relatively shorter than the data block requested by the destination node, it may be more efficient to transcode the key rather than the data.

[0107] According to several approaches, data (e.g., unencrypted data) comprises multiple data chunks, each data chunk having its own associated fingerprint, or its own computed fingerprint, or both. Each fingerprint may be computed using SHA-256 or other secure hash algorithms known in the art. The fingerprint may be doubly encrypted in at least some of the embodiments described herein. The encrypted fingerprint may be used in secure deduplication using a per-chunk key so that the fingerprint data is securely transcoded for use at a destination node. The encrypted fingerprint may be used to determine dedup opportunities, as an end-to-end integrity check, to provide additional data privacy, etc. The number of keys for transcoding data, fingerprints, metadata, etc., to securely share them may be any number, according to at least some of the operations described herein. In the preferred approach of the embodiments described above, each data chunk is associated with at least one unique key compared to other data chunks (e.g., encrypted / decrypted by that key). In various approaches, each data chunk of data, each fingerprint, or both may be associated with its own first key, second key, or first and second keys. In this way, in at least some embodiments of the present disclosure, forward secrecy can be provided by modifying at least one key for each data chunk destined for the destination node. The destination node has its data chunks in plaintext (after transcoding, if applicable), but the source node can define the amount of data the destination node receives by modifying the key for each data chunk.

[0108] Next, Figure 7 is a flowchart of Method 700 according to one embodiment. Method 700 can be carried out in various ways in any of the environments shown in Figures 1-6 and Figure 7 in particular, according to a preferred embodiment of the present invention. Of course, as will be understood by those skilled in the art by reading this specification, Method 700 may include more or fewer operations than those specifically described in Figure 7.

[0109] Each step of Method 700 may be performed by any suitable component in the operating environment. For example, in various embodiments, Method 700 may be performed in part or in whole by a computer or any other device having one or more processors. One or more steps of Method 700 may be performed by utilizing a processor (e.g., a processing circuit, chip or module or combination thereof implemented in hardware or software or both, preferably having at least one hardware component) in any device. Examples of processors, but not limited to, include central processing units (CPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and combinations thereof, as well as any other suitable computing device known in the art.

[0110] As shown in Figure 7, method 700 includes operation 702, which includes receiving a second encrypted key by the transcoder. The second encrypted key is obtained by encrypting the key with the first key to create the first encrypted key, and then encrypting this with the second key to obtain the second encrypted key. In a preferred embodiment, the encryption of the key into the first encrypted key and then the encryption of the first encrypted key into the second encrypted key are performed at the source node. The source node includes the first key and the second key.

[0111] Operation 704 includes the transcoder receiving a second key. In various approaches, the second key is received from the source node. In various approaches, the source node sends a copy of the second key to the transcoder, which securely stores the second key for a period, number of operations, etc., as defined by the sharing policy information. In at least some embodiments, in response to the termination of the sharing period (e.g., due to a decision by the sharing policy or a request from the source node), the transcoder may shred the second key, replace the second key with a dummy key, or both, as will be apparent to those skilled in the art by reading this disclosure. The dummy key may be of any type known in the art.

[0112] In other approaches, the second key may be received from a key manager. The key manager may be coupled to the source node, destination node, or any other component or combination in the network to provide, generate, and manage keys for sharing data between the source node and the destination node.

[0113] Operation 706 includes the transcoder decrypting the second encrypted key using the second key to obtain the first encrypted key. As described above, the second encrypted key is obtained by encrypting the key with the first key to create the first encrypted key, and then encrypting this with the second key to obtain the second encrypted key. According to operation 706, the transcoder may obtain the first encrypted key using the encryption / decryption function in the transcoder and the second key (which in some approaches is sent from the source node). Preferably, the transcoder does not have access to the first key (for example, to decrypt the first encrypted key and obtain the key) and cannot obtain the plaintext key.

[0114] Operation 708 includes the transcoder encrypting the first encrypted key using a third key to create a third encrypted key. The first encrypted key (for example, encrypted only with the first key) may be encrypted with a new third key by an encryption / decryption function on the transcoder to create a third encrypted key. The encryption / decryption function may be the same as or different from the encryption / decryption function of operation 706 (for example, a separate function dedicated to the third key). In at least some approaches, the third key may be generated by the transcoder using a key generator on the transcoder. In other approaches, arbitrary keys may be generated or managed or both by a key manager or key generator, or both, coupled to the source node, transcoder, destination node, etc.

[0115] In at least some approaches, Method 700 includes the transcoder sending a third key to the destination node. In various approaches, the transcoder sends a copy of the third key to the destination node, which securely stores the data for a period, number of operations, etc., as defined in the sharing policy information. In a preferred embodiment, in response to the termination of the sharing period (e.g., due to a decision by the sharing policy or a request from the source node), the transcoder shreds the third key, replaces the third key with a dummy key, or both, in any manner obvious to those skilled in the art by reading this disclosure, in order to terminate data sharing between the source node and the destination node. The dummy key may be of any type known in the art.

[0116] In other approaches, the third key may be sent from the key manager to the destination node. The key manager may be coupled to the source node, destination node, or any other component or combination in the network to provide, generate, and manage keys for sharing data between the source node and the destination node.

[0117] Operation 710 includes the transcoder sending a third encrypted key to the destination node. The third encrypted key is obtained by encrypting the first encrypted key (for example, the key encrypted with the first key) with the third key, as described above. In various approaches, the destination node receives the first key directly from the source node. In various approaches, the destination node is configured to decrypt the third encrypted key using the third key and obtain the first encrypted key using an encryption / decryption function on the destination node. The destination node is configured to decrypt the first encrypted key using the first key and obtain the key using an encryption / decryption function on the destination node (which may be the same as or different from the encryption / decryption function used to decrypt the third encrypted key and obtain the first encrypted key). As described above, the key may be a plaintext key or an unencrypted key, etc.

[0118] In various approaches, the destination node may use a key (e.g., an unencrypted key) to decrypt the data from the source node. For example, this unencrypted key may be the first key in at least some of the operations described in method 600 in Figure 6.

[0119] The present invention may, according to preferred embodiments, be a system, method, or computer program product or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium storing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0120] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may, for example, be an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, punch cards, or mechanically encoded devices with instructions recorded on them, and suitable combinations thereof. The computer-readable storage mediums used herein should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0121] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing device / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, LAN, WAN, or wireless network, or a combination thereof). The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers or edge servers, or a combination thereof. A network adapter card or network interface within each computing device / processing device receives computer-readable program instructions from the network and transfers them for storage in a computer-readable storage medium in each computing device / processing device.

[0122] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions can be executed as a standalone software package, either entirely on the user's computer or partially on the user's computer. Alternatively, they can be executed partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including LANs and WANs, or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), and programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of computer-readable program instructions in order to customize the electronic circuits for the purpose of performing aspects of the present invention.

[0123] Aspects of the present invention are described herein with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. Each block in a flowchart or block diagram, or both, and combinations of blocks in a flowchart or block diagram, or both, are executable by computer-readable program instructions.

[0124] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine. This creates a means for these instructions, executed via such a computer or other programmable data processing device processor, to perform functions / operations identified in one or more blocks in a flowchart or block diagram, or both. These computer-readable program instructions can further be stored in a computer-readable storage medium that can be instructed to function in a particular manner to a computer, programmable data processing device, or other device, or a combination thereof. Thus, the computer-readable storage medium containing the instructions constitutes a product containing instructions for performing functions / operations identified in one or more blocks in a flowchart or block diagram, or both.

[0125] Alternatively, a computer execution process may be generated by loading computer-readable program instructions into a computer, another programmable device, or other device, and having a series of operational steps executed on that computer, other programmable device, or other device. This ensures that the instructions executed on the computer, other programmable device, or other device perform functions / operations identified by one or more blocks in a flowchart, block diagram, or both.

[0126] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions containing one or more executable instructions for performing a specific logical function. In some other implementations, the functions shown within a block may be executed in an order different from the order shown in each diagram. For example, depending on the functions involved, two consecutively shown blocks may actually be achieved as a single process, executed simultaneously or nearly simultaneously, executed in a manner that partially or entirely overlaps in time, or the blocks may be executed in reverse order. Each block in a block diagram or flowchart or both, and combinations of multiple blocks in a block diagram or flowchart or both, are executable by a dedicated hardware-based system that performs a specific function or operation, or executes a combination of dedicated hardware and computer instructions.

[0127] Furthermore, systems according to various embodiments may include a processor and logic that is integrated into the processor, or executable by the processor, or both, and which is configured to perform one or more of the process steps described herein. "Integrated" means that the logic is embedded in the processor as hardware logic such as an application-specific integrated circuit (ASIC), FPGA, etc. "Executable by the processor" means that the logic is hardware logic, software logic such as firmware, part of an operating system, part of an application program, etc., or any combination of hardware logic and software logic that is accessible by the processor and is configured to cause the processor to perform some function when executed by the processor. The software logic may be stored in local memory, remote memory, or both of any memory type known in the art. Any processor known in the art may be used, such as a software processor module, or a hardware processor such as an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), graphics processing unit (GPI), etc., or both.

[0128] It is clear that multiple combinations can be created from the above description by combining various features of the above-described systems, methods, or both in any way.

[0129] It is further understood that embodiments of the present invention can be provided as a service deployed on behalf of the customer to provide services on demand.

[0130] While various embodiments of the present invention have been described as examples, they are not intended to be exhaustive or limit the invention to these embodiments. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope and spirit of each embodiment described. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the technology observed in the market of each embodiment, or to enable other those skilled in the art to understand each embodiment disclosed herein.

Claims

1. The transcoder receives the second encrypted data, and this second encrypted data is obtained by first encrypting the data with the first key to create the first encrypted data, and then encrypting the first encrypted data with the second key to create the second encrypted data. The transcoder receives the second key, The transcoder decrypts the second encrypted data using the second key and obtains the first encrypted data. The transcoder generates a third key, uses the newly generated third key to encrypt the first encrypted data, and creates the third encrypted data. The transcoder transmits the third encrypted data to the destination node, The transcoder includes transmitting the newly generated third key to the destination node, The destination node is configured to decrypt the third encrypted data using the newly generated third key and obtain the first encrypted data, and the destination node is configured to decrypt the first encrypted data using the first key and obtain the data. Computer implementation method.

2. The computer implementation method according to claim 1, wherein the second key is received from the source node.

3. The computer implementation method according to claim 1, wherein the second encrypted data is received at least in part based on a data request from the transcoder to storage.

4. The computer implementation method according to claim 2, wherein the second encrypted data is received at least in part based on a data request from the transcoder to the source node.

5. The data comprises multiple data chunks, each data chunk is encrypted with a fourth key, the fourth key is encrypted with the first key to become the first encrypted fourth key, the first encrypted fourth key is then encrypted with the second key to become the second encrypted fourth key, and the method is as follows: The transcoder receives the second encryption fourth key, The transcoder decrypts the second encryption fourth key using the second key and obtains the first encryption fourth key. The transcoder generates a third key, uses the newly generated third key to encrypt the first encryption fourth key, and creates a third encryption fourth key. The transcoder transmits the newly generated third key to the destination node, The transcoder transmits the third encryption fourth key to the destination node, The computer implementation method according to claim 1, including the method described in claim 1.

6. The computer implementation method according to claim 2, wherein the transcoder is located on the source node.

7. The computer implementation method according to claim 3, wherein the transcoder is located on the storage.

8. The computer implementation method according to claim 3, wherein the transcoder is located on a storage network coupled to the source node and the storage.

9. The computer implementation method according to claim 1, further comprising replacing the third key with a dummy key in order to terminate data sharing between the source node and the destination node by the transcoder.

10. The computer implementation method according to claim 1, wherein the first, second, and third encrypted data refer to the first, second, and third encrypted keys.

11. The transcoder includes transmitting the third key to the destination node, The computer implementation method according to claim 10, wherein the destination node is configured to decrypt the third encrypted key using the third key and obtain the first encrypted key, and the destination node is configured to decrypt the first encrypted key using the first key and obtain the key.

12. The computer implementation method according to claim 11, wherein the destination node decrypts the data from the source node using the key.

13. The transcoder receives a second encrypted key, and this second encrypted key is obtained by first encrypting the key with the first key to create the first encrypted key, and then encrypting the first encrypted key with the second key to obtain the second encrypted key. The transcoder receives the second key, The transcoder decrypts the second encrypted key using the second key and obtains the first encrypted key. The transcoder generates a third key, uses the newly generated third key to encrypt the first encrypted key, and creates a third encrypted key. The transcoder transmits the third encrypted key to the destination node, The transcoder includes transmitting the newly generated third key to the destination node, the destination node is configured to decrypt the third encrypted key using the newly generated third key and obtain the first encrypted key, and the destination node is configured to decrypt the first encrypted key using the first key and obtain the key. Computer implementation method.

14. The computer implementation method according to claim 13, wherein the destination node decrypts the data from the source node using the key.

15. Processor and A system comprising logic integrated into the processor, logic executable by the processor, or logic integrated into and executable by the processor, wherein the logic is The transcoder receives the second encrypted data, and this second encrypted data is obtained by first encrypting the data with the first key to create the first encrypted data, and then encrypting the first encrypted data with the second key to create the second encrypted data. The transcoder receives the second key, The transcoder decrypts the second encrypted data using the second key and obtains the first encrypted data. The transcoder generates a third key, uses the newly generated third key to encrypt the first encrypted data, and creates the third encrypted data. The transcoder transmits the third encrypted data to the destination node, The logic is configured to send the new third key generated by the transcoder to the destination node. The destination node is configured to decrypt the third encrypted data using the newly generated third key and obtain the first encrypted data, and the destination node is configured to decrypt the first encrypted data using the first key and obtain the data. system.

16. The system according to claim 15, wherein the second key is received from the source node.

17. The system according to claim 15, wherein the second encrypted data is received at least in part based on a data request from the transcoder to storage.

18. The system according to claim 16, wherein the second encrypted data is received at least in part based on a data request from the transcoder to the source node.

19. The data includes multiple data chunks, each data chunk is encrypted with a fourth key, the fourth key is encrypted with the first key to become the first encrypted fourth key, the first encrypted fourth key is then encrypted with the second key to become the second encrypted fourth key, and the logic is, The transcoder receives the second encryption fourth key, The transcoder decrypts the second encryption fourth key using the second key and obtains the first encryption fourth key. The transcoder generates a third key, uses the newly generated third key to encrypt the first encryption fourth key, and creates a third encryption fourth key. The transcoder transmits the newly generated third key to the destination node, The transcoder transmits the third encryption fourth key to the destination node, The system according to claim 15, configured to perform the following:

20. The system according to claim 16, wherein the transcoder is located on the source node.

21. The system according to claim 17, wherein the transcoder is located on the storage.

22. The system according to claim 17, wherein the transcoder is located on a storage network coupled to the source node and the storage.

23. The system according to claim 15, wherein the logic is configured such that the transcoder replaces the third key with a dummy key in order to terminate data sharing between the source node and the destination node.

24. It is a computer program, A program instruction for receiving second encrypted data by a transcoder, wherein the second encrypted data is created by first encrypting data with a first key to create first encrypted data, and then encrypting the first encrypted data with a second key to create second encrypted data; The transcoder provides a program instruction for receiving the second key, The transcoder provides program instructions for decrypting the second encrypted data using the second key and obtaining the first encrypted data, The transcoder generates a third key, uses the newly generated third key to encrypt the first encrypted data, and provides program instructions for creating the third encrypted data. The transcoder provides program instructions for sending the third encrypted data to the destination node, and a program instruction for sending a new third key generated by the transcoder to the destination node, wherein the destination node is configured to decrypt the third encrypted data using the generated new third key to obtain the first encrypted data, and the destination node is configured to decrypt the first encrypted data using the first key to obtain the data. Computer program.

25. It is a computer program, A program instruction for receiving a second encrypted key by a transcoder, wherein the second encrypted key is obtained by first encrypting the key with the first key to create the first encrypted key, and then encrypting the first encrypted key with the second key to obtain the second encrypted key, and The transcoder provides a program instruction for receiving the second key, The transcoder provides program instructions for decrypting the second encrypted key using the second key and obtaining the first encrypted key, The transcoder generates a third key, uses the newly generated third key to encrypt the first encrypted key, and provides program instructions for creating a third encrypted key. The transcoder provides program instructions for sending the third encrypted key to the destination node, and a program instruction for sending the new third key generated by the transcoder to the destination node, the destination node configured to decrypt the third encrypted key using the generated new third key to obtain the first encrypted key, and the destination node configured to decrypt the first encrypted key using the first key to obtain the key. Computer program.

26. A computer program comprising program code means adapted to perform the method described in any one of claims 1 to 14 when the program is executed on a computer.

Images