How encryption keys are handled for file backup

Overview

For file backup purposes, the Code42 agent maintains an encryption key on each user's computer that encrypts files before sending them for storage in Code42 cloud archives, and decrypts the files when they are restored from archives. A copy of the encryption key is held in escrow in Code42's keystore for limited use cases. This article describes how Code42 handles these encryption keys.

For information about how encryption keys are handled for access to collected security data as well as preserved files, see Code42 architecture.

Considerations

• For more information about how Code42 handles encryption keys, contact your Customer Success Manager (CSM).
• For our policies regarding law enforcement requests to Code42 to release data, see FAQs about law enforcement requests for Code42 customer information.

Typical Code42 agent session with the Code42 cloud

During a typical session when the Code42 agent sends files to the Code42 cloud for storage in an archive, the Code42 agent identifies changes to files on the computer, organizes those changes into blocks, compresses the blocks, and encrypts the blocks using an encryption key stored on the computer where the Code42 agent is installed.

The encryption key is stored on the computer in a key-value pair binary datastore and is only readable by the Code42 service. The encryption key is automatically removed when the user or computer is deauthorized.

The Code42 service then transmits the encrypted blocks over an encrypted TLS channel to the storage server in the Code42 cloud. When the encrypted blocks arrive at the storage server, Code42 appends them to the archive in the opaque encrypted form in which they were transmitted. 

Once the files are in the Code42 cloud, access to encrypted files is only available through authenticated sessions with the storage server. Non-administrative users are only authorized to access their own archives and only through an authenticated Code42 application protocol session with the storage server. 

Encryption key creation

The following diagram illustrates a typical flow when encryption keys are created. This occurs on the first occasion that a Code42 agent authenticates with the Code42 cloud. Steps where the key is handled are shown in bold.

1. The user is authenticated in the Code42 agent.
2. The Code42 agent on the user's computer generates a unique 256-bit AES encryption key.
3. The Code42 agent contacts the authority service in the Code42 cloud. 
4. A new account enrollment is initiated in the keystore for the user.
5. A certificate is passed to the authority service to verify the user.
6. A new keystore account is created for the user.
7. The encryption key originally generated by the end user's Code42 agent is escrowed in the Code42 keystore.
8. The user is authorized by the authority service.
9. The Code42 agent securely maintains a persistent copy of the encryption key on the computer for its day-to-day use. 

Incydr Gov F1

For Incydr Gov F1, the keystore resides in the authority service.

1. The user is authenticated in the Code42 agent.
2. The Code42 agent on the user's computer generates a unique 256-bit AES encryption key.
3. The Code42 agent contacts the authority service in the Code42 cloud. 
4. An archive key is placed into the keystore service embedded in the authority service.
5. An escrowed key is saved.
6. The user is authorized by the authority service.
7. The Code42 agent securely maintains a persistent copy of the encryption key on the computer for its day-to-day use. 

The Code42 keystore

A copy of your users' encryption keys is held in Code42's keystore for limited use cases. Code42 cannot query for, read, or directly access your users' escrowed encryption keys. All content of the Code42 keystore is encrypted, and there is no master key to the Code42 keystore. 

Code42 runs its keystore in a highly available and redundant manner, and regularly creates snapshots to allow for disaster recovery. All data in the Code42 keystore is encrypted at rest and requires a Code42 controlled key to be provided every time the system is restarted. There are a select number of Code42 employees with access to the credentials for the keystore system. However, administrative access to the keystore does not enable access to the keys themselves or to the data secured by the keys. The only method to access a key is through an authenticated session with the Code42 service, either as the user owning the key, or as an authorized administrator performing a restore on a user's behalf.

Local access to the Code42 keystore server, like all other Code42 cloud services, is restricted to a very limited number of operations engineers. The Code42 keystore itself is "sealed" at rest. To unseal the keystore via local system access and to make it operational on startup, the Code42 keystore requires three out of five separate keys, each supplied by different individuals at Code42. These unseal keys are managed in a separate secrets management system, which requires additional layers of authentication, including muti-factor authentication. Access of any of these keys triggers alerts to the Code42 Security team. Access to the unseal keys is only authorized under explicit scenarios where the service must be restarted. Even in those instances, access to the keys does not equate to access to the data. 

When Code42 retrieves keys from the keystore

Escrowed user encryption keys are accessed from the Code42 keystore in the following situations:

• File restore and archive maintenance
  Using normal user authentication and authorization, the Code42 cloud reads an encryption key from the Code42 keystore for archive maintenance and when restoring data via the Code42 console or the Code42 API. 
• Computer replacement
  In situations where a user replaces a computer, the user must first authenticate before being authorized to access their own archive encryption key from the Code42 keystore. The key is then stored on the new computer in the same method as on the computer that originally generated the key.
• Customer requests
  In exceptional cases, Code42 can retrieve keys from the Code42 keystore on behalf of authenticated and authorized customer administrators. In these cases, the key is stored in memory until the successful completion of the restore operation that required the key access, at which point it is purged from memory. At no point does Code42 have access to the content of the keys.

Related topics

• Manage your archive keystore 
• Archive keystore reference 
• FAQs about law enforcement requests for Code42 customer information
• Incydr architecture