How CrashPlan handles your encryption keys for file backup

Overview

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

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

Considerations

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

Typical CrashPlan app session with the CrashPlan cloud

During a typical session when the CrashPlan app sends files to the CrashPlan cloud for storage in an archive, the CrashPlan app 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 CrashPlan app is installed.

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

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

Once the files are in the CrashPlan 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 CrashPlan 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 CrashPlan app authenticates with the CrashPlan cloud. Steps where the key is handled are shown in bold.

1. The user is authenticated in the CrashPlan app.
2. The CrashPlan app on the user's computer generates a unique 256-bit AES encryption key.
3. The CrashPlan app contacts the authority service in the CrashPlan 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 CrashPlan app is escrowed in the CrashPlan keystore.
8. The user is authorized by the authority service.
9. The CrashPlan app securely maintains a persistent copy of the encryption key on the computer for its day-to-day use. 

The CrashPlan keystore

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

CrashPlan runs its keystore in a highly available and redundant manner, and regularly creates snapshots to allow for disaster recovery. All data in the CrashPlan keystore is encrypted at rest and requires a CrashPlan controlled key to be provided every time the system is restarted. There are a select number of CrashPlan 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 CrashPlan 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 CrashPlan keystore server, like all other CrashPlan cloud services, is restricted to a very limited number of operations engineers. The CrashPlan keystore itself is "sealed" at rest. To unseal the keystore via local system access and to make it operational on startup, the CrashPlan keystore requires three out of five separate keys, each supplied by different individuals at CrashPlan. 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 CrashPlan 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 CrashPlan retrieves keys from the keystore

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

• File restore and archive maintenance
  Using normal user authentication and authorization, the CrashPlan cloud reads an encryption key from the CrashPlan keystore for archive maintenance and when restoring data via the CrashPlan console or the CrashPlan 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 CrashPlan 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, CrashPlan can retrieve keys from the CrashPlan 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 CrashPlan have access to the content of the keys.