File Content Storage Security



Code42 takes the security of your data very seriously. We have created a system designed to protect that data from unauthorized access. Original file content is encrypted, organized in an archive, and stored within the Code42 cloud. Access to the original file content is controlled by two things: authorized access to the archive and possession of the user’s archive encryption key. We adhere to some of the most stringent industry security standards and requirements, including holding ISO and SOC2 certifications. Independent third parties regularly review, audit, and penetration test our software as well as our enterprise business and production operations.

  • Data is stored in a secure archive
  • Each user has its own archive with distinct and strong access controls
  • Each user has a unique 256-bit AES encryption key
  • Possession of the archive encryption key does not authorize a user to access the archive contents
  • Aside from authenticated and authorized endpoint devices, Code42 encryption keys are only stored in escrow within the Code42 keystore, a logically and physically separated environment from other components of the Code42 cloud
  • There is no master key to the Code42 keystore
  • All content of the Code42 keystore is encrypted at rest
  • Only Code42 authority systems are allowed to connect to the keystore at the network level
  • Neither Code42 support, nor Code42 application administrators, can query for, or directly access, users’ encryption keys
  • There is no mechanism for undetected key or data access by a Code42 employee

The Code42 Archive

All file content data is encrypted and then stored within an optimized, secure, unique and distinct location for each user and device. This location is known as an archive. The Code42 App on endpoint devices authenticates with storage services and establishes a secure session to the Code42 cloud.  During the session, changes to files on the endpoint are identified, those changes are organized into blocks which are encrypted and compressed before being sent to the storage node. The encrypted blocks are then transmitted over an encrypted TLS channel to the storage server. When the encrypted blocks arrive at the storage node they are appended to the archive in the opaque encrypted form in which they were transmitted..  Access to archive content is only available through authenticated sessions with the storage node server. Non-administrative users are only authorized to access their own archives and only through an authenticated Code42 application protocol session with the storage node.

Purpose of Keys in Code42 Operations

Code42 stores file contents in a separate archive for each endpoint (end user computer). These archives are encrypted using a unique 256-bit AES encryption key for each user, which is generated by the end user’s endpoint app the first time it authenticates with the Code42 cloud. The Code42 endpoint app securely maintains a persistent copy of this key on the endpoint for its day-to-day functionality.  In order to ensure access to data, Code42 operates a keystore which escrows a copy of the users’ keys. Other than the end user’s endpoints, the Code42 keystore is the only location where a copy of the user’s encryption key is persistently stored.

Archives, Keys, and Encryption in Day-to-Day Operations

The archive encryption keys that are securely persisted on endpoints are used to encrypt file contents prior to transmission to the cloud over a secure channel. Additionally, each endpoint uses the key stored on the endpoint when performing file restores from the cloud.

In exceptional cases, keys are retrieved from the Code42 keystore by the Code42 product automatically on behalf of authenticated and authorized customer administrators.  These cases must be requested through the application by a properly scoped, authenticated, and authorized customer administrator and include web and push restores where the Code42 cloud or a secondary Code42 client must obtain the key in order to perform a restore.In these cases, the key is stored in memory until the successful completion of the restore at which point it is purged from memory.

In situations where a user is migrating to a new endpoint, whether because the original endpoint has been lost or stolen, or because of a device migration, the user must first authenticate before being authorized to access its own archive encryption key from the Code42 keystore. At this point, the key is then stored on the new endpoint in the same method as on the endpoint which originally generated the key.

Security of your data goes beyond the security of encryption keys, because access to a Code42 encryption key by itself does not allow access to data stored within Code42. Data is stored in a separate system from the keys and can only be accessed by an authenticated and authorized Code42 endpoint or cloud service as part of the regular authentication and authorization workflow.

Code42 Keystore Operation 

The Code42 keystore is an automated platform service that provides highly-available, secure storage of encryption keys with layers of access controls that ensure only authorized system actors may retrieve a key. All operational key access is performed systematically, not manually. All key access is one-at-a-time, not bulk. All keys are scoped to the data and account of a single Code42 user.

There are numerous technical and procedural controls in place to secure the integrity and availability of the Code42 keystore. These controls include:

  • Logical and physical separation of the keystore from the rest of the Code42 service
  • Limited access controls
  • Full audit logging for all operational and “break glass” access to the Code42 keystore
  • Logical separation of keys by tenant
  • Strong authentication per each user in each tenant
  • Encryption of key material in-flight and at rest

All data in the 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 for accessing a key is through an authenticated session through the Code42 service, either as the user owning the key, or an authorized administrator performing a restore on their behalf.


How are the keys stored on the endpoint?

The key is stored in a mechanism called "authorized storage." It is a key-value pair binary datastore that encrypts all values at rest, is only readable by the service, and is automatically removed when the user or device is deauthorized. On Windows, this store leverages the DPAPI (data protection API). On other platforms, a key is generated using other platform facilities to uniquely encrypt the values at rest.


What access restrictions and controls are in place for Code42 keystore system administrator accounts?

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. The Code42 keystore requires 3 out of 5 separate keys to unseal the keystore via local system access and to make it operational on startup. These unseal keys are managed in a separate secrets management system, which requires additional layers of authentication including MFA. Access of any of these keys triggers alerts to Code42 security. Access to the unseal keys is only authorized under explicit scenarios where the service must be restarted and even in those instances, access to the keys does not equate to access to data. See above for details.

What if Code42 is served with a law-enforcement request to release data?

See our full policy on law-enforcement requests for data here.

What does Code42 use for its keystore backend?

We use an open-source product called Hashicorp Vault although we may change the exact technology used to escrow keys from time to time. Code42 runs our Vault instance in a highly available, redundant, and regularly snapshotted manner to allow for disaster recovery.

Want to learn more?

Contact Code42 to learn more about Next-Gen DLP.