Encryption Overview

Uptivity supports file level encryption (FLE) for most media (that is, audio and screen recording) and data files. Files are encrypted on the recording server(s) as they are written to disk using AES-256-bit encryption. This provides full end-to-end protection, as files are never left on disk in an unencrypted format.

If encryption is enabled on an existing system, new files (that is, files recorded after the feature is enabled) are encrypted as they pass through the TranscoderClosedAn Uptivity service that converts raw files recorded by the system into compressed, formatted files optimized for storage and playback.. Existing recording files can be encrypted using a tool available to Uptivity support personnel. Contact Support for more information.

You can verify whether a file is encrypted by opening the file in a text editor. If the file is encrypted, the first 5 characters in the file will be CCENX.

Encryption keys are stored in the Uptivity database. If the database becomes unavailable while CTI CoreClosedThe software component that provides the PBX/ACD integration and makes call recording decisions based on customer-defined recording schedules. is running, encryption continues operating. However, CTI Core instances that utilize encryption cannot be started or restarted without a connection to the database. For security reasons, encryption keys cannot be stored locally to allow for this.

Audio and video files generated while encryption was enabled can only be played while encryption is enabled.

Encryption Exceptions

Some files cannot be encrypted in Uptivity. These include:

  • ShoreTel TAPI/WAV recordings — This recording method generates unencrypted .wav files. Since Uptivity relies on a third-party library to generate these files, the application cannot encrypt them while they are writing. The Transcoder service can convert the files to an encrypted format if/when they are transcoded.
  • XML files — Uptivity can generate XML files that contain call metadata. However, these files are not required. To turn off XML file generation, contact Uptivity Support.

Encryption Key Management

Encryption keys are critically important. If a key is lost, any recordings encrypted with that key will be completely and irretrievably inaccessible.

Thales Encryption vs. Standard Key Management

Uptivity can integrate with Thales Encryption Key Management for customers who already use this product. The Thales systems offers a similar degree of security and flexibility as the built-in functionality of Uptivity. The main difference is the extra hardware, cost, and configuration required when integrating Thales into the Uptivity environment. For more information, talk to your Uptivity Sales Engineer.

Increased Security by Cycling Keys

You can increase the security of encryption by periodically generating a new key. The risk in changing keys is that anything encrypted with the old key will no longer be accessible unless steps are taken to retain and secure it. If the old key is lost, any recordings encrypted with it will be permanently inaccessible.

If the customer only wants one active key the in the database, the old key(s) can either be disabled and kept in the database, or backed up as a physical keyfile and stored in a secure location, and then reactivated if calls encrypted with the old key(s) need to be accessed.

The following use cases demonstrate the possible methods of retaining and securing old keys. For information about the steps involved in managing keys and encrypted files, see Manage Database Keys and Manage Encrypted Recordings.

Customer Use Case 1: Cycle Keys but keep Old Keys Active

The customer wants to cycle to a new database key, but retain the old database key(s) in an active state so previously-encrypted files are still playable.

  1. Generate a new active key.
  2. Restart all services.
  3. Database contains multiple active keys, and all calls in the system can be played back.

Customer Use Case 2: Cycle Keys but Disable Old Keys

The customer wants to cycle to a new database key and retain the old key(s), but keep them in a disabled state. The previously-encrypted files will not be accessible.

  1. Generate a new active key.
  2. Deactivate the previous active key.
  3. Restart all services.
  4. The database contains one active key and one or more inactive keys, and only calls encrypted with the new key can be played back.

To access calls encrypted with the old keys: 

  1. Reactivate the old key(s).
  2. Restart services.
  3. Calls encrypted with the reactivated key(s) can now be played back.
  4. When the customer has finished working with the older calls, deactivate the old key(s) again.

To access a single call encrypted with an old key: 

  1. Locate the key used to encrypt the call in question.
  2. Activate only the key needed to play back the call.
  3. Decrypt the call.
  4. Play back the call.
  5. When the customer has finished working with the call, deactivate the key again.

Customer Use Case 3: Cycle Keys and Keep Old Keys in a Physical Keyfile

The customer wants to cycle to a new database key and keep the old database key(s) as a physical keyfile in a secure location. Any calls encrypted with the old key(s) will not be accessible.

  1. Export the current key to a keyfile.
  2. Generate a new active key.
  3. Delete the old key from the database.
  4. The database contains one active key.
  5. Only calls encrypted with the new key can be played back.

To access calls encrypted with the old keys: 

  1. Import the old keys needed to play back calls.
  2. Restart services.
  3. Calls encrypted with the imported key(s) can be played back.
  4. When done working with the calls, delete the imported key(s) from the database.

To play back a single call encrypted with a key that has been removed from the database: 

  1. Locate the key used to encrypt the call in question.
  2. Decrypt the call in question using the correct keyfile and password.