End-to-end encryption and backup in data protection environments

Abstract

A computer-implemented method for performing a backup of a set of objects by a client, at least one of the objects of the set of objects being associated with and encrypted with a unique file encryption key (FEK), the method comprising: Encrypting each of the FEKs with a common master encryption key (MEK), whereby the encryption results in corresponding locked keys; during an initial backup operation, transferring the encrypted objects together with their associated revoked keys to a backup server; by a first module, determining whether an event has occurred in which a locked key of an object has changed due to a change in the MEK, wherein the change in the locked key is determined via an encryption state associated with the objects whose FEKs are affected by the change in the MEK, and wherein the encryption state indicates the change; and based on determining that an event has occurred in which a revoked key of an object has changed due to a change in the MEK, re-encrypting the existing FEKs with the changed MEK, wherein the re-encryption results in new revoked keys, and wherein, in a subsequent backup operation, the new revoked keys are sent to the backup server to replace the existing revoked keys, while the objects whose associated FEKs are affected by the changed MEK are not transferred to the backup server.

Description

BACKGROUND

[0001] The present invention relates to the field of digital computer systems, and more particularly, to a method for backing up and restoring encrypted file objects in a computer system. Currently, an encrypted file encrypted using file system techniques and to be backed up must first be decrypted using the file system techniques and then re-encrypted using the backup client and its server techniques to store it in an encrypted format on the backup server. Conversely, a file to be restored from the backup server must first be decrypted using backup server techniques and then re-encrypted after it has arrived back on the file system.

[0002] The document US 2011 / 0293096 A1 describes a key manager that provides a way to separate the management of encryption keys and policies from application domains.

[0003] The document US 2012 / 0297189 A1 describes procedures and systems for the secure implementation of external storage providers in an enterprise.

[0004] Document US 2006 / 0126850 A1 describes one or more clients communicating with a server. The client wishes to send a storage construct to the server for storage. The client negotiates a transfer key with the server. The client generates a storage key specifically associated with the storage construct. The client encrypts the storage construct with the storage key and encrypts the storage key with the transfer key. The encrypted storage construct and the encrypted storage key are sent to the server. The server decrypts the storage key using the transfer key. The server stores the storage construct on a storage device separate from a storage device that stores the storage key.

[0005] Document EP 2 730 049 B1 describes systems, methods, and non-transitory computer-readable storage media for wireless data backup using cryptographic key management on a primary device and a backup device. A system encrypts a file with a file key and encrypts the file key twice, resulting in two encrypted file keys. The system encrypts each file key differently and stores a first file key on the primary device and transmits one of the encrypted file keys, in addition to the encrypted file, to a backup device for storage. On the backup device, the system links the encrypted file key to a set of backup keys protected by a user password. SUMMARY

[0006] The invention is described by the features of the independent claims. Embodiments are specified in the dependent claims.

[0007] Various embodiments provide a system and method for backing up and restoring files encrypted by file system encryption techniques.

[0008] According to one embodiment of the present invention, a computer-implemented method for performing a backup of a set of objects by a client is described, wherein at least some of the objects of a set of objects are each linked and encrypted with a unique file encryption key FEK.The method comprises: encrypting each of the FEKs with a common master encryption key MEK, wherein the encryption results in locked keys; transferring the encrypted objects in an initial backup operation together with their associated locked keys to a backup server; determining, by a first module, whether an event has occurred in which a locked key of an object has changed due to a change in the MEK, wherein the change in a locked key is determined via an encryption state associated with the object whose FEKs are affected by the change in the MEK, wherein the encryption state indicates the change, and in the case of a changed MEK, re-encrypting the existing FEKs with the changed MEK, wherein this re-encrypting results in new locked keys.In a subsequent backup operation, the new revoked keys are sent to the backup server to replace the existing revoked keys.

[0009] According to one embodiment of the present invention, a computer-implemented method for restoring a backup of a set of objects by a client is described. Here, at least some of the objects of the object set are each associated with and encrypted with a unique file encryption key (FEK), wherein at least some of the FEKs stored in the backup are encrypted with a common master encryption key (MEK), wherein this encryption results in corresponding locked keys stored in the backup. Each object contained in the backup is associated with an encryption state, wherein the encryption state indicates whether the locked key has changed with respect to the current backup due to a change in the MEK.The method further comprises receiving a request to restore one of the objects, the method comprising: determining whether the encryption state associated with the object to be restored indicates that the locked key has changed since the backup was performed; if the encryption state associated with the object to be restored indicates that the locked key has changed since the current backup was performed, ignoring the object during the restore; if the encryption state associated with the object to be restored indicates that the locked key has not changed since the current backup was performed, restoring the encrypted FEK associated with the object and the object.

[0010] A further embodiment is described herein, wherein a client computer is configured to perform a client backup of a set of objects, at least some of the objects of the set of objects being associated with or encrypted with a unique file encryption key FEK, the client computer comprising a processor and a memory, the memory comprising computer-executable instructions.The execution of the instructions by the processor causes the client to: encrypt each of the FEKs with a common master encryption key MEK, where the encryption results in corresponding locked keys; transfer the encrypted objects, along with their associated locked keys, to a backup server in an initial backup operation; determine whether a locked key of an object has changed due to a change in the MEK, where the change in the locked key is determined via an encryption state associated with the objects whose FEKs are affected by the change in the MEK, where the encryption state indicates the change; and, in the case of a changed locked key, re-encrypt the existing FEKs with the changed MEK.This re-encryption results in new revoked keys, which are sent to the backup server in a subsequent backup operation to replace the existing revoked keys.

[0011] According to one embodiment, a client computer is described that is configured to restore a backup of a set of objects by a client, comprising: the backup is stored on a backup server, wherein at least some of the objects of the set of objects are associated with or encrypted with a unique file encryption key FEK, wherein at least some of the FEKs in the backup are encrypted with a common master encryption key MEK. This encryption results in corresponding locked keys stored in the backup. Each object included in the backup is associated with an encryption state, wherein the encryption state indicates whether the locked key has changed with respect to the current backup due to a change in the MEK. The client computer comprises a processor and a memory, wherein the memory comprises computer-executable instructions.Execution of the instructions by the processor causes the client to receive a request to restore one of the objects and, in response to receiving the request, to determine whether the encryption state associated with the object to be restored indicates that the locked key has changed since the current backup was performed; if the encryption state associated with the object to be restored indicates that the locked key has changed since the current backup was performed, ignoring the object during restoration; if the encryption state associated with the object to be restored indicates that the locked key has not changed since the current backup was performed, restoring the encrypted FEK associated with the object along with the object.

[0012] According to one embodiment, a computer program product is described comprising computer-executable instructions for performing any of the steps described above associated with the end-to-end backup and restore procedure for encrypted and unencrypted file objects. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In the following, embodiments of the invention are explained in more detail by way of example only with reference to the drawings in which: Fig. 1 shows an encryption key hierarchy for the file system according to an embodiment of the invention. Fig. 2 illustrates an end-to-end encryption / decryption flow according to an embodiment of the invention. Fig. 3 shows a backup architecture for a cluster file system according to an embodiment of the invention. Fig. 4 shows a flowchart of end-to-end backup encryption according to an embodiment of the invention. Fig. 5 shows a flowchart for restoring a backed up file object according to an embodiment of the invention. Fig. 6 shows examples of a table generated to track encryption key changes and a recovery decision matrix according to an embodiment of the invention. Fig. 7 illustrates a block diagram illustrating hardware components of data processing units in the system 200 of Fig. 2 according to an embodiment of the invention. EXACT DESCRIPTION

[0014] The descriptions of the various embodiments of the present invention are presented for purposes of illustration, but are not intended to be exhaustive or limiting to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical application, or technical improvement over technologies commonly available in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0015] In a conventional computer system having one or more computer storage nodes connected via a network and providing a shared file system, where at least one computer storage node hosts a backup client and the backup client is connected to a backup server, the file system provides the functionality to encrypt and decrypt file data, while the backup client and backup server provide the functionality to encrypt and decrypt file data. However, the encryption and decryption functions of the file system are different from the encryption and decryption functions of the backup client and server. The encryption method for the file system and the backup client and server use hierarchies of encryption keys, but the file encryption keys are incompatible.A file encrypted with file system techniques that is to be protected by the backup client and server must first be decrypted using the file system techniques and re-encrypted using the backup client and server techniques to store it in an encrypted format on the backup server. Conversely, to restore a file encrypted with backup system techniques to the backup server, the file must first be decrypted using these techniques and then re-encrypted using the file system techniques after it arrives in the file system.

[0016] The present method provides a means for backing up and restoring files encrypted using file system encryption techniques. The file is encrypted using the file system encryption and can be backed up in this format without decryption and re-encryption using backup system techniques. Therefore, a file encrypted using file system encryption techniques is backed up in exactly this format. This can have the advantage of avoiding decryption using file encryption techniques and re-encryption using backup system techniques, thus saving computing time.

[0017] By tracking encryption key changes for files whose contents have not changed between backups but whose encryption keys have changed, the technique allows a subsequent backup to back up only the changed encryption key, rather than the entire file contents. This can have the advantage of accelerating a backup operation and avoiding the transfer of unchanged file data already on the backup server.

[0018] In the event that a file object needs to be restored using a copy of it on the backup server, the method also provides a means to determine whether a recoverable copy of that file exists on the backup server. This can have the advantage of avoiding the case where a file's encryption key has changed, which is not reflected in the copy present on the backup server.

[0019] The term "file encryption key" refers to a key used to encrypt sections of a file. As long as the contents of the file remain unchanged, the file encryption key remains unchanged. If the file is modified, a new file encryption key is generated.

[0020] The term "master encryption key" refers to a key used to encrypt other keys, but which is not itself encrypted. Master encryption keys can also be passwords. Typically, master encryption keys are stored in a key store or key management software outside the encrypted file system. File encryption keys encrypted with the master encryption key result in "locked keys."

[0021] According to one embodiment, the method comprises determining, by the first module, whether a new FEK is available, wherein the availability of the new FEK is determined via the encryption state associated with the object whose FEK is new, and the encryption state indicates the availability of the new FEK. If the new FEK is available, the new FEK is encrypted with the currently available MEK to obtain the associated revoked key. In the subsequent backup operation, the object associated with the new FEK and encrypted with it together with the associated revoked key is transferred to the backup server. This can have the advantage that both the file data and its associated encryption are up-to-date on the backup server.

[0022] According to a further embodiment, the new FEK may be the result of one of the following events: an object associated with a FEK has been modified and therefore re-encrypted with the new FEK; a new object has been created and encrypted with the new FEK; a previously unencrypted object of the object set has been encrypted with the new FEK.

[0023] According to one embodiment, the method comprises, in response to the first module detecting the event of a new FEK, automatically updating the encryption state for the object associated with the new FEK, wherein the updating comprises: if the object already has an associated encryption state, replacing an existing encryption state for the object; or if the object has no associated encryption, associating a new encryption state with the object associated with the new FEK. This may have the advantage that the current encryption FEK associated with a file can be properly taken into account and updated in a future backup operation. This may also have the advantage that in case of restoring a file from the backup server, the current FEK is available.

[0024] When the object is recreated, a new encryption state can be created for the object immediately by the first module. Or the newly created object can be logged first during the subsequent backup. Automatically updating the encryption state for the object associated with the new FEK can have the advantage of ensuring that the encryption information on the backup server matches the encryption information for the local file object.

[0025] According to one embodiment, the first module updates the encryption state for all file objects after performing the subsequent backup, wherein updating comprises: optionally changing the encryption state from indicating the availability of a new FEK to indicating that the FEK is unchanged; optionally changing the encryption state from indicating that the MEK has changed to indicating that the FEK is unchanged. Indicating an unchanged FEK indicates that both the contents of the file object and the associated FEK are current at the time of the backup. Thus, in the event of a restore operation, the unchanged FEK state indicates that restoring the file object from the backup is permissible because the file object and its associated FEK on the backup server match the local file object and its associated FEK.

[0026] In one embodiment, in the case of a newly created encrypted file whose existence is only logged during the subsequent backup, updating comprises indicating that the associated FEK of the encrypted file is unchanged. In the case of a newly created unencrypted file whose existence is logged during the subsequent backup, updating comprises indicating that no FEK is associated with the unencrypted file.

[0027] This update can have the advantage that when performing a subsequent backup, all objects that have an associated encryption state indicating that the FEK is unchanged will be excluded from the backup. This can reduce both the time and the amount of computing resources required for the subsequent backup.

[0028] According to one embodiment, for which an object in the set of objects is unencrypted and not associated with an FEK, the associated encryption state indicates the unavailability of an FEK for the object. To perform the subsequent backup, the method comprises: the first module determining the objects for which the associated encryption state indicates the unavailability of the FEKs; and a second module determining the need for a backup of the objects for which the associated encryption state indicates the unavailability of the FEKs. Determining the need for the backup is based on a direct scan of the objects. This can have the advantage that file objects that are not associated with an FEK are still backed up to the backup server.

[0029] In one embodiment, when the first module receives as an event a request to delete an encrypted object of the set of objects, the present method comprises changing the encryption state associated with the object to a state indicating the unavailability of an FEK for that object. This may have the advantage of allowing an indication of a deleted object to be achieved without physically deleting the object from the server. Since physically deleting a large object that occupies extensive memory could cause computer operations to slow down, changing the associated FEK, which is a small and single object, may be advantageous and much faster.

[0030] In one embodiment, the first module comprises an event handler that automatically detects the event, and in response to automatically detecting the event, the event handler automatically performs an update of the encryption state affected by the event. This may have the advantage of automatically updating the encryption states and keeping them up-to-date.

[0031] According to one embodiment, the present method comprises determining an indication of the encryption state associated with the object to be restored, regardless of whether a new FEK is available for the object. The new FEK may be the result of one of the following events: the object associated with the FEK was modified and therefore re-encrypted with the new FEK after the initial backup; the object is a new object that was created and encrypted with the new FEK after the initial backup and whose creation was immediately logged by the event handler; the object is a previously unencrypted object that was encrypted with the new FEK after the initial backup.

[0032] If the encryption state indicates that a new FEK is available for the object being restored, the object being restored is ignored during the restore. If the encryption state indicates that a new FEK is not available for the object being restored, the object being restored is restored along with its associated encrypted FEK.

[0033] According to one embodiment, if the object to be restored has been newly created since the last backup and was not logged immediately upon creation by the event handler, the method comprises determining that the restore is not possible because the object to be restored is not included in the last backup.

[0034] This recovery procedure can have the advantage that only files on the backup server with current FEKs in the file system can be restored.

[0035] According to one embodiment, the present method further comprises determining whether the encryption state associated with the object to be restored indicates that no FEK is available for the object. In such a case, the object is restored if the object is included in the backup that does not have a corresponding revoked key associated with it. However, if no FEK is associated with the object, but the object is included in the backup that does have a corresponding revoked key associated with it, the object to be restored is ignored during the restore.

[0036] Fig. Figure 1 shows an encryption key hierarchy for the file system. Components 101 (FEK1, FEK2, and FEK3) correspond to respective FEKs for file system objects. Each of these FEKs is encrypted in turn by component 103, the MEK, resulting in locked keys. The MEK 103 is used to encrypt FEKs 101, but is not itself encrypted. The MEK 103 can also be passwords. In such a system, file objects are encrypted with a unique FEK 101. These FEKs 101 are then each encrypted with the universal MEK 103 to form locked keys. The locked key for a file object is stored along with the file object on the backup server.

[0037] Fig. Figure 2 shows an example process for end-to-end encryption / decryption. For a backup operation, file objects are created on the client 201. If a file object is to be encrypted, an associated FEK (101 in Fig. 1) is used for encryption. A locked key is then generated by encrypting the FEK 101 with the MEK (103 in Fig. 1). During a backup operation, the encrypted file is transferred via the data storage server 203 to the backup system 205. If the file is encrypted, the locked key is transferred along with the associated file. The storage server 203 may be network storage. For a restore operation, files located on the backup system 205 are transferred through the computer data storage server 203 to be restored on the client machine 201. If the file is encrypted, its locked key is transferred along with the file to be restored. The end-to-end encryption method ensures that a current version of the file and its locked key is available on the backup server if a restore operation is to be permitted.

[0038] Fig. Figure 3 shows a backup architecture for a cluster file system. One or more client computers 301 assigned to component 201 of Fig. 2, are connected to storage computer nodes 303, 305, 307. One or more of these storage computer nodes 303, 305, 307 may be present. Each of the client computers 301 and storage computer nodes 303, 305, 307 consists of a processor 309, a memory 311, and an input / output controller 313. The representative client computers 301 are connected to a cluster storage system, which is an example of the computer data storage server 203 of Fig. 2. The cluster storage system includes storage computer nodes 303, 305, 307; a storage area network 315; and one or more disk storage components 317, 319, 321. Part of the cluster file system backup architecture includes a backup client component 323 on which an encryption key event handler module 325 is located.

[0039] The encryption key event handler 325 logs changes in the FEK states of all existing or newly created file objects. The backup client 323 and its resident encryption key event handler 325 are connected to a backup server 327 corresponding to component 205 of Fig. 2. This connection enables the backup and restore of file system objects between the local computer nodes 303, 305, 307 and the backup server 327. In a backup operation, the backup client 323 has, based on the information collected in the encryption key event handler 325, the necessary information to decide whether, in the case of a modified or newly created file, the complete file with its associated FEK must be sent to the backup server 327, or in the case of a newly encrypted existing file or a file whose locked key has changed due to a change in the MEK (103 in Fig. 1), only the locked key and not the file content needs to be sent to the backup server 327.

[0040] Similarly, during a restore operation, the encryption key event handler 325 can be used to determine whether the file and its locked key are current on the backup server 327 and thus eligible for restoration. The encryption key event handler 325 also indicates whether the file contents or its locked key are not current on the backup server 327 and therefore prevents a restore operation from occurring.

[0041] Fig. 4 shows a flow chart of end-to-end backup encryption, which describes the Fig. 2 in more detail. Block 401 corresponds to the beginning of the process. In block 403, data from an encrypted file object is read for a file that was not previously backed up and transferred to the backup server (component 327 in Fig. 3). In block 405, the metadata of the file object, which contains the locked key as well as information such as source, author, creative software, and the creation date of the file, is read and copied to the backup server. In block 407, for an encrypted file object, its associated locked key, which is obtained by encrypting the FEK (101 in Fig. 1) with the MEK (103 in Fig. 1) is read from the metadata for use in block 409. In block 409, the ID and an unchanged encryption state of the secured file object are added to a secured object table maintained by the encryption key event handler 325 of Fig. 3 is registered. Or, in the case of an existing entry in the table, the information is updated to indicate an unchanged encryption state relative to the local copy of the object. The process ends in block 411.

[0042] Fig. 5 shows a flow chart illustrating the Fig. 2 highlighted restore process in more detail. The restore process, in which a backed up file is restored to the file system, can only occur if the encryption key event handler (325 in Fig. 3) information is determined that both the contents of the file and the locked key located on the backup server (327 in Fig. 3) are up-to-date. This means that the encryption key for the file on the backup server is up-to-date, which is reflected in the table of file objects and their associated encryption states. The process for determining this is as follows: If the specification in the table for the encryption key event handler (325 in Fig. 3) For a file object to be restored, if its associated FEK is new and an FEK exists on the backup server, restoring is not allowed. This is because the associated FEK on the backup server does not match the current FEK associated with the local file, meaning the file contents on the backup are not current and therefore cannot be restored. In this case, if no FEK exists on the backup server, restoring is also not allowed because the encryption states on the backup server and the local server associated with the file to be restored do not match, resulting in an encryption state associated with the file that is not current.

[0043] If the table entry for the file object to be restored indicates that the associated FEK has been changed and an FEK exists on the backup server, no restore is allowed. This is because, in this case, a changed FEK indicates that the MEK (103 in Fig. 1), which is used to generate locked keys from the corresponding FEKs, has changed. Therefore, the backed up file cannot be properly decrypted upon restoration due to the changed locked key. In this case, if no FEK is present on the backup server, restoration is not permitted because the encryption state on the backup server for the file being restored indicates an unencrypted file, while the file is actually encrypted.

[0044] If the file encryption state for the file object being restored indicates that no encryption state exists for the file object and an FEK exists on the backup server, restoring is not allowed. This is because the local file being restored is not encrypted, while its copy on the backup server is encrypted. However, if no FEK exists on the backup server, restoring is allowed for the file object without an associated encryption state because both the local file being restored and the backup copy are not encrypted. In this case, it is necessary to check whether the contents of the file have been changed by a normal backup procedure, since its contents may change but remain unencrypted.

[0045] If a file object is being restored whose table entry indicates an unchanged file encryption state and an FEK exists on the backup server, a restore is permitted because an unchanged state indicates that both the contents and the locked key for the backup server copy of the file being restored match the contents and locked key for the local file. In this case, it is not possible for an FEK to be present on the backup server.

[0046] The process begins in block 501. In block 503, the restore client receives encrypted file object data from the backup server and writes the encrypted data to the file system. In block 505, the restore client receives file object metadata containing the file object's locked key from the backup server and writes the metadata to the file system. In block 507, the restore client selects the file object's locked key associated with the object from the received metadata for use in block 509. In block 509, the encryption state of the restored file object is reset in the backed up file object table maintained in the encryption key event handler 325 of Fig. 3 are resident to indicate an unchanged encryption state. The process ends in block 511.

[0047] Fig. 6 shows an example of table 601 used in the encryption key event handler (325 in Fig. 3) after a first backup operation. An example of the table after a subsequent backup operation is shown in 603. The created and updated table is stored in step 409 by Fig. 4. As described in detail for Fig. 5, in determining whether a restore operation of a file from the backup server is permitted, the restore decision matrix 605 is invoked by the encryption key event handler (325 in Fig. 3) is used.

[0048] The innovative backup client (323 in Fig. 3) and the backup server (327 in Fig. 3) can solve the problem that a file must be decrypted and re-encrypted when a backup copy is created using a pass-through encryption method. Furthermore, the problem that changes in the encryption key hierarchy cannot be automatically detected can be solved by a novel system of encryption event handling routines (325 in Fig. 3) are resolved. Therefore, changes in the encryption key hierarchy that invalidate backup copies are handled by initiating new backup copies of files as needed. Automatically detecting encryption key changes and initiating updates to the file on the backup server avoids the problem of the file version not being recoverable on the backup server due to changed encryption keys.

[0049] Fig. Figure 3 shows a system for end-to-end backup encryption, ETEBE, which includes the first module for implementing single end-to-end file encryption and continuously detecting changes in the encryption key hierarchy. If the backup copy of a file becomes invalid due to changes in the encryption key, such changes are automatically detected by a module with an encryption key event handler EKEH (325 in Fig. 3 and according to an example of the first module) which is logged in the backup client (323 in Fig. 3), and in a backup operation, this information is used to determine whether the file contents need to be backed up along with their associated encryption key or whether only the encryption key needs to be backed up.

[0050] The EKEH module (325 in Fig. 3) maintains a table for each secured file system (301 in Fig. 3). The table contains the file system identifier FS-ID, which is a unique identifier for identifying the file system. The table also contains an object identifier, Obj-ID, which is a unique identifier for the specific file system, such as files and directories that have already been backed up by the backup client (323 in Fig. 3). Each file system object, identified by its unique Obj ID, appears only once in the table. The table also contains a file encryption key state, FEK state, which can take the following values: NEW (file encryption key is new and no key is present in the backup), CHANGED (file encryption key has been changed since the last backup), NO-FEK (file has been decrypted and no encryption key is present in the file system), and UNCHANGED (encryption keys in the file system and backup are irrelevant; revert to UNCHANGED after a successful backup without encryption key changes).

[0051] The ETEBE system and procedure are configured to automatically detect changes to encryption keys in the file system as follows: As an example for the first module, the EKEH module (325 in Fig. 3) Encryption key events for files that are already secured. The registered events are: CREATE (occurs when an encryption key is created for a file system object - this means that the file system object has been re-encrypted either due to the newly created file system object, a change in its contents, or the encryption of a previously unencrypted file system object), CHANGE (occurs when an encryption key for a file system object has changed due to the MEK (103 in Fig. 3), which has been changed, which causes the FEKs (101 in Fig. 1) be re-encrypted, resulting in new locked keys), and DESTROY (occurs when an encryption key for a file system object has been deleted - meaning that the file system object has been decrypted).

[0052] The encryption key events are used to update the table with the appropriate information resulting from the event type.

[0053] The ETEBE system and procedure are configured to read an encrypted file and create an incremental backup copy without decrypting the information through the steps described in Fig. 4. The ETEBE system and procedure are also configured to provide information about the ability to retrieve a file from the backup server (327 in Fig. 3). The steps to restore an encrypted file in the file system (301 in Fig. 3) are in Fig. 5. First, however, the backup procedure is explained in detail.

[0054] During a first backup, the backup client (323 in Fig. 3) an incremental backup copy of the file system by traversing the file system structure and reading the file data for each file and copying it to the backup server (327 in Fig. 3). If the file data is encrypted, the encrypted data is sent without decryption, and the encryption key is also sent to the backup server (327 in Fig. 3). For each backed-up file system object, an entry is created in the table with the specified FS ID and Obj ID. The FEK State column is populated as follows: If the file system object has a file encryption key (FEK), the FEK state is listed as UNCHANGED. If the file system object does not have a file encryption key (FEK), the FEK state is listed as NO-FEK.

[0055] After an initial backup, the table can be restored as after the initial backup 601 of Fig. 6 appear shown.

[0056] After an initial backup, the encryption key events CREATE, CHANGE, and DESTROY are used to update the table with the appropriate information in the FEK State column, which results from the event type. The EKEH (325 in Fig. 3) retrieves the object ID from the event and searches the corresponding entry in the table. The EKEH (325 in Fig. 3) Retrieves the event type from the event and updates the FEK state column in the table as follows: In the case of the "CREATE" event type, the FEK state changes from "NO-FEK" to "NEW." In the case of the "CHANGE" event type, the FEK state changes from "NEW" or "UNCHANGED" to "CHANGED." In the case of the "DESTROY" event type, the FEK state changes from "NEW," "UNCHANGED," or "CHANGED" to "NO-FEK." The table is updated continuously based on the received event until the next backup is performed.

[0057] During a subsequent backup, the backup client (323 in Fig. 3) an incremental backup copy of the file system by traversing the file system structure and reading the file data of the changed files, as was done in the prior art, and copying them to the backup server (327 in Fig. 3). If the file data is encrypted, the encrypted data is sent without decryption, and the encryption key is also sent to the backup server (327 in Fig. 3) sent. For each backed up file system object for which no entry exists in the table, an entry is created with the given FS-ID and Obj-ID. The FEK State column is populated as follows: If the file system object has a file encryption key (FEK), the FEK state is listed as UNCHANGED. If the file system object does not have a file encryption key (FEK), the FEK state is listed as NO-FEK. If an entry for the backed up file system object exists in the table, the FEK state for that entry is set to UNCHANGED.

[0058] After a subsequent backup, the table may appear as shown in the following backup 603 in Fig. 6 shown.

[0059] During a file restore, the backup client (323 in Fig. 3) for each requested object, whether restore is allowed. This is necessary to avoid situations where the file in the file system has a new FEK (101 in Fig. 1), while the backed up version of the file has an old or nonexistent FEK (101 in Fig. 1) and would overwrite the local file with incorrect information. To determine this, the backup client (323 in Fig. 3) a matrix to determine whether a restore is allowed. The matrix contains the FEK status for the local file, which is known from the table, and the information whether the corresponding file stored on the backup server (360 in Figure 3) has an FEK. The matrix form is represented by the restore decision matrix 605 in Fig. 6 illustrates.

[0060] For a file object that exists in the local file system and requires overwriting or placing the file object in a different location, using the matrix involves searching for a file object by its Obj-ID, reading its FEK state, and querying the backup server (327 in Fig. 3) for information about whether the backed up object has an FEK. This information is then used to find the row with the corresponding FEK status for the local file and the column with the corresponding FEK status for the backed up file on the backup server (327 in Figure 3). Find the intersection and determine whether a restore is allowed.

[0061] As can be seen from the matrix, there are only two states for which a restore is allowed, namely: i) if the local file has no FEK and the corresponding file on the backup server (327 in Fig. 3) also has no FEK; and ii) if the local file has an unchanged FEK and the corresponding file on the backup server (327 in Fig. 3) also has an FEK.

[0062] If the ETEBE system has determined that a restore is allowed, the backup client (323 in 3) executes the Fig. 5 to copy the backed up file from the backup server to the local file system.

[0063] Fig. Figure 7 shows a block diagram of components of data processing units used in the system 200 of Fig. 2, according to an embodiment of the present invention. It should be noted that Fig.7 merely provides an illustration of one implementation and does not imply limitations on the environments in which different embodiments may be implemented. Many modifications may be made to the illustrated environment.

[0064] Data processing units may include one or more processors 02, one or more computer-readable RAMs 04, one or more computer-readable ROMs 06, one or more computer-readable storage media 08, device drivers 12, a read / write drive or interface 14, a network adapter or network interface 16, all interconnected via a data exchange structure 18. The data exchange structure 18 may be implemented using any architecture configured to pass data and / or control information between processors (such as microprocessors, data transfer and network processors, etc.), system memory, peripherals, and any other hardware components in a system.

[0065] One or more operating systems 10 and one or more application programs 11 are stored on one or more of the computer-readable storage media 08 for execution by one or more of the processors 02 via one or more of the corresponding RAMs 04 (which typically include cache memory). In the illustrated embodiment, each of the computer-readable storage media 08 may be a magnetic disk storage device of an internal hard disk drive, a CD-ROM, a DVD, a memory stick, a magnetic tape, a magnetic disk, an optical disk, a semiconductor storage device such as RAM, ROM, EPROM, flash memory, or any other computer-readable tangible storage device capable of storing a computer program and digital information.

[0066] The data processing unit may also include a read / write drive or interface 14 for reading from and writing to one or more portable, computer-readable storage media 26. Application programs 11 in the data processing unit may be stored on one or more of the portable, computer-readable storage media 26, read via the corresponding read / write drive or interface 14, and loaded into the corresponding computer-readable storage medium 08.

[0067] Computing units may also include a network adapter or interface 16, such as a TCP / IP adapter card or a wireless data transmission adapter (such as a 4G wireless data transmission adapter using OFDMA technology). Application programs 11 on computing units may be downloaded to the computing unit from an external computer or external storage device via a network (e.g., the Internet, a local area network, or other wide area or wireless network) and network adapter or interface 16. From the network adapter or interface 16, the programs may be loaded onto computer-readable storage media 08. The network may include copper wires, fiber optic cables, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers.

[0068] Data processing devices may also include a display screen 20, a keyboard or keypad 22, and a computer mouse or touchpad 24. Device drivers 12 interface with display screen 20 for imaging, keyboard or keypad 22, computer mouse or touchpad 24, and / or display screen 20 for print capture of alphanumeric character input and to display user selections. Device drivers 12, R / W drive or interface 14, and network adapter or interface 16 may comprise hardware and software (stored on computer-readable storage media 08 and / or ROM 06).

[0069] The programs described herein are identified based on the application for which they are implemented in a specific embodiment of the invention. However, it should be noted that any particular program nomenclature is used herein merely for convenience, and therefore, the invention should not be limited to exclusive use in any specific application identified and / or implied by such nomenclature.

[0070] Based on the foregoing, a computer system, a method, and a computer program product have been disclosed. However, numerous modifications and substitutions may be made without departing from the scope of the present invention. Therefore, the present invention has been disclosed by way of example and not by way of limitation.

[0071] The present invention may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium(s) having computer-readable program instructions stored thereon for causing a processor to perform aspects of the present invention.

[0072] The computer-readable storage medium may be any physical device capable of retaining and storing instructions for use by an instruction-executing system. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM).Flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as containing transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., pulses of light carried through a fiber optic cable), or electrical signals carried through a wire.

[0073] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.

[0074] Computer-readable program instructions for performing operations of the present invention may be assembly language instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code, written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, as well as conventional procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, over the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention.

[0075] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, may be implemented by computer-readable program instructions.

[0076] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine such that the instructions, executed via the processor of the computer or other programmable data processing device, produce a means for implementing the functions / steps defined in the block(s) of flowchart and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having instructions stored thereon comprises an article of manufacture, including instructions that implement aspects of the function / step specified in the flowchart block(s) and / or block diagrams.

[0077] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of process steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-executable process such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / steps defined in the block(s) of flowchart and / or block diagrams.

[0078] The flowcharts and block diagrams in the figures 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 the flowcharts or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for performing the particular logical function(s). In some alternative implementations, the functions indicated in the block may occur in a different order than shown in the figures. For example, two blocks shown in sequence may actually execute substantially concurrently, or the blocks may sometimes execute in reverse order depending on the corresponding functionality.It is further understood that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or steps, or by combinations of special purpose hardware and computer instructions.

Claims

[1] A computer-implemented method for performing a backup of a set of objects by a client, at least one of the objects of the set of objects being associated with and encrypted with a unique file encryption key (FEK), the method comprising: Encrypting each of the FEKs with a common master encryption key (MEK), whereby the encryption results in corresponding locked keys; during an initial backup operation, transferring the encrypted objects together with their associated revoked keys to a backup server; by a first module, determining whether an event has occurred in which a locked key of an object has changed due to a change in the MEK, wherein the change in the locked key is determined via an encryption state associated with the objects whose FEKs are affected by the change in the MEK, and wherein the encryption state indicates the change; and based on determining that an event has occurred in which a revoked key of an object has changed due to a change in the MEK, re-encrypting the existing FEKs with the changed MEK, wherein the re-encryption results in new revoked keys, and wherein, in a subsequent backup operation, the new revoked keys are sent to the backup server to replace the existing revoked keys, while the objects whose associated FEKs are affected by the changed MEK are not transferred to the backup server. [2] The method of claim 1, further comprising: determining by the first module whether a new FEK is available, wherein the availability of the new FEK is determined via the encryption state associated with the objects whose FEK is new, and wherein the encryption state indicates the availability of the new FEK; based on determining that a new FEK is available, encrypting the new FEK with the currently available MEK to obtain the associated revoked key; and In the subsequent backup operation, the encrypted object with the new FEK is transferred to the backup server along with the corresponding revoked key. [3] The method of claim 2, wherein the new FEK is the result of detecting at least one of the following events: an object belonging to an FEK was modified and therefore re-encrypted with the new FEK, a new object was created and encrypted with the new FEK, and a previously unencrypted object of the object set was encrypted with the new FEK. [4] The method of claim 3, wherein the method further comprises: based on the detection of the event, the first module updating the encryption state for the object associated with a new FEK, wherein updating the encryption state for the object associated with the new FEK further comprises: Determine whether the object already has an associated encryption state; based on determining that the object already has an associated encryption state, replacing an existing encryption state for the object; Determine whether the object has no associated encryption state; based on determining that the object has no associated encryption state, associating a new encryption state with the object that is associated with the new FEK; Determine whether the object was newly created; and Based on determining that the object has been newly created, generating a new encryption state for the object. [5] The method of claim 2, further comprising: by the first module updating the encryption state after performing the subsequent backup, wherein updating the encryption state after performing the subsequent backup further comprises: if necessary, changing the encryption state from indicating the availability of a new FEK to indicating that the FEK is unchanged; and if appropriate, changing the encryption state from an indication that the MEK has changed to an indication that the FEK is unchanged, whereby objects with an associated encryption state indicating that the FEK is unchanged are excluded from any subsequent backup. [6] The method of claim 1, wherein the associated encryption state for an object of the set of objects that is unencrypted and not associated with a FEK indicates the unavailability of a FEK for the object, and wherein performing a subsequent backup further comprises: by the first module, determining the objects for which the associated encryption state indicates the unavailability of the FEKs; and by a second module, determining the need for a backup of the objects for which the associated encryption state indicates the unavailability of the FEKs, whereby the determination of the need for the backup is based on a direct scanning of the objects. [7] The method of claim 1, further comprising: Receiving, as an event, a request to delete an encrypted object of the set of objects; and Changing the encryption state associated with the encrypted object to a state that indicates the unavailability of an FEK for the encrypted object. [8] The method of claim 1, wherein the first module includes an event handler, and wherein the method further comprises: by the event handler detecting the event; and In response to detecting the event, the event handler updates the encryption state affected by the event. [9] A computer-implemented method for restoring, by a client, a backup of a set of objects, at least one of the objects of the set of objects being associated with and encrypted with a unique file encryption key (FEK), at least one of the FEKs being stored in the backup encrypted with a common master encryption key (MEK), wherein the encryption results in corresponding locked keys, the locked keys being stored in the backup, each object included in the backup being associated with an encryption state, the encryption state indicating whether the locked key has changed with respect to the current backup due to a change in the MEK, the method comprising: Receiving a request to restore one of the objects; Determine whether the encryption state associated with the object to be restored indicates that the locked key has changed since the current backup was performed; based on determining that the encryption state associated with the object to be restored indicates that the locked key has changed since the current backup was performed, ignoring the object during the restore; and based on determining that the encryption state associated with the object to be restored indicates that the revoked key has remained unchanged since the most recent backup was performed, restoring the encrypted FEK associated with the object and the object. [10] The method of claim 9, further comprising: Determine whether the encryption state associated with the object to be restored indicates that a new FEK is available, where the new FEK is the result of at least one of the following events: the object associated with the FEK was modified and therefore re-encrypted with the new FEK after the initial backup; the object is a new object created after the initial backup and encrypted with the new FEK; and the object is a previously unencrypted object that was encrypted with the new FEK after the initial backup; based on determining that the encryption state associated with the object to be restored indicates that a new FEK is available, ignoring the object to be restored; and based on the determination that the encryption state associated with the object to be restored indicates that no new FEK is available, the object to be restored and the encrypted FEK associated with the object are restored. [11] The method of claim 9, further comprising: Determine whether the encryption state associated with the object to be restored indicates that no FEK is available; based on determining that the encryption state associated with the object to be restored indicates that no FEK is available, determining whether the object to be restored is associated with a corresponding revoked key in the backup; based on determining that the object to be restored is not associated with a corresponding locked key in the backup, restoring the object to be restored, and based on determining that the object to be restored is associated with a corresponding locked key in the backup, ignoring the object to be restored.

Images