Encryption Overview

Encryption in Hosted Systems

inContact WFO supports file level encryption for all audio, screen recording, and data files. Audio files are recorded, maintained, and played back from within the inContact cloud environment, and are encrypted there. If the system includes inContact Screen Recording, workstation activity is recorded on the PREMISES server and screen recordings are encrypted there prior to being moved to cloud storage.

Files remain on the PREMISES server only until they are transmitted to the cloud. This is a variable period depending on network connectivity, bandwidth, and other factors.

Encryption keys are stored in a "keyring" file on the PREMISES server. You should never delete or deactivate keys from the keyring file. A copy of the keyring file can be provided by your inContact WFO deployment team, and should be stored in a secure, offline location.

inContact WFO 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 inContact WFO 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 inContact WFO 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 theinContact WFO system to facilitate access to historical media.

Encryption is activated as soon as a database key is generated. Any inContact WFO 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

inContact WFO 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 inContact WFO 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. inContact WFO 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: