Encryption Overview
Encryption is an optional, chargeable feature in Uptivity.
Uptivity supports file level encryption 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 Transcoder.
Encryption keys are stored in the Uptivity database. If the database becomes unavailable while CTI Core 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.
To disable encryption, consult Uptivity Support. All audio and video files generated after encryption is disabled will not be encrypted. However, audio and video files generated while encryption was enabled can no longer be played unless encryption is re-enabled. Attempting to play such a recording results in an error.
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
Uptivity uses a multiple-key approach to create an "envelope" of security for each file, as shown in the following image.
Each encrypted media file includes the components shown here. These components are:
- Media (1) — the actual bytes representing a call or screen recording and its associated metadata
- File Key (2) — a dynamically-generated, single use key that is used to encrypt the media
- Database Key Fingerprint (3) — the database key is used to encrypt the file key. Since an Uptivity system may have multiple database keys, each media file includes a fingerprint (that is, a hash) of its database key.
Database keys are stored in the Uptivity database, and the use of multiple database keys is supported. The fingerprint included in the media file tells the software which database key to use to decrypt the file key without exposing the database key itself.
When multiple database keys are present, the most recent is used to encrypt the file key for newly acquired media. Previous database keys are retained by theUptivity system to facilitate access to historical media.
Encryption is activated as soon as a database key is generated. Any Uptivity module that uses encryption must be able to query the database in order to encrypt/decrypt files. If there are active keys in the database, the modules supporting encryption automatically load and use them on startup. Modules also check for changes and reload keys once every 15 minutes.
Definition Keys
Uptivity further encrypts stored database keys using a definition key. Two classes of definition keys are supported, but only one can be used in a given Uptivity system:
- Embedded key — an embedded definition key (also known as the DLL key) is hard-coded in the software and is the same for every customer
- File-based keys — file-based definition keys can be generated and controlled by the customer
Regardless of which class of definition key is used, only one definition key can be used at a time, and it controls all database keys.
Cycling Definition Keys
Many customers require the ability to change or cycle the key used to encrypt persisted data. This capability may be needed on a regular basis, such as for PCI compliance, or on an ad hoc basis if there is suspected or actual loss of trust in a key. Uptivity supports this requirement only when file-based definition keys are used.
Cycling the definition key re-encrypts the database key without changing it. The process is comparable to locking a key in a safe and periodically changing the safe combination. It allows organizations to meet compliance standards while minimizing encryption upkeep and user impact.
The following events take place as part of cycling a definition key:
- A new file-based definition key is created
- The previous file-based definition key is used to decrypt each database key
- Each database key is re-encrypted using the new filed-based definition key
After cycling, the previous file-based definition key is obsolete and should be discarded. The following considerations apply to cycling definition keys:
Encryption keys are critically important. If a key is lost, any recordings encrypted with that key will be completely and irretrievably inaccessible.
The following recommendations are considered best practices for encryption key management:
- Never delete keys from the database.
- If you generate a new key, export it using the cc_crypt.exe utility. Keep the exported file in a secure location that is backed up regularly. This will help guard against possible loss of data.
- Do not deactivate keys when there are active files using those keys. Wait until any files with that key are no longer needed and have been purged from your system.
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