Browse
 
Tools
Rss Categories

Encrypting Call Files

Reference Number: AA-01857 Views: 3612 0 Rating/ Voters

LumenVox software can be configured to produce response files, or .callsre files.  These files contain diagnostic tuning information about ASR and TTS interactions that can be later analyzed and used to improve IVR application performance.

As of LumenVox version 11.3.100, these response files can be configured to be encrypted when they are produced, thereby securing any potentially sensitive data, such as personally identifiable information, or credit card information that may be part of the data stored in these files.

In order to produce these response files, you should review the Logging Call Files article, which explains how this can be done.  For more information about data security and the various features provided by LumenVox software, you should read the Securing Sensitive Data article.


How Response File Encryption Works

The mechanism we used when encrypting response files is based on Pretty Good Privacy (PGP), which provides cryptographic privacy and authentication, created by Phil Zimmermann in 1991.

The LumenVox encryption mechanism is based on the creation and use of "public certificate" and "private key" pairs.  These pairs must be produced at the same time, and provide a mechanism to encrypt data, using the "public certificate" and also later decrypt the data into its original form using a "private key" that matches the "public certificate" that was used during encryption.  This process is similar to that shown in the diagram below (from the earlier referenced wikipedia.org page).


A random key is also used to "seed" the encryption process each time encryption is invoked, producing an encrypted key that is used during encryption, and is stored with the encrypted data.

The decryption process involves being able to access the "private key", which can be used to decrypt the encrypted key, and transform the data back to its unencrypted (original) form.


Controlling Access To Keys/Certificates

It is vital to securely control the distribution of the keys and certificates.  The certificates are designed to be public, meaning that there is no risk in distributing or publishing these to many people, even strangers, since that only provides them the ability to be able to encrypt data to be sent to you.  Indeed it is essential that these certificates are made available for that purpose.

Private keys, however need to be protected safely, and certainly not distributed to unauthorized people, since these private keys hold the power to decrypt any data that was encrypted with the public certificate.


Additional Security Features

This PGP mechanism has some interesting and useful additional features. 

Multiple Keys

One interested feature of the LumenVox/PGP encryption mechanism is the ability to utilize multiple public-certificate / private-key pairs if needed.  This means that if you wanted 2 different people to be able to access the same encrypted data, they do not both need to have access to the same private-key.

For example, if you wanted to give Mary access to the encrypted data, and also wanted Fred to get access to it, but they didn't want to share each others private keys (since that may be protecting other more sensitive data), then the encryption algorithm can use both Mary's and Fred's public certificates during the encryption phase.  This allows either Mary's private key or Fred's private key to independently decrypt the data.

You might be asking yourself why is this useful to you. Well, if you need to comply with some security standard(s) and need to guard your private keys under strict security, and you also needed to share some encrypted response files with LumenVox, you could simply enable encryption with your public certificate, and also the LumenVox public certificate, which would allow LumenVox engineers to access that data, but it would not give them access or any knowledge of your private key, which will remain secure.  This way, you control who gets access to secured data, whether that be a single private key or multiple private keys. The choice is yours.

Obviously if LumenVox engineers need to gain access to the data, for diagnostic, or tuning purposes, then it will be necessary to add their public certificate to those being used during encryption.

You can have several certificate/key pairs assigned to the encryption algorithm, as defined using the LOGGING_ENCRYPTION_KEY setting in client_property.conf,

Password Protection

An additional safety feature that can be used to protect private-key usage is the ability to assign a Password/Passphrase to the key when it is created. When this is done, the user will be prompted for the passphrase which needs to be provided before decryption will take place, meaning the person attempting to access the encrypted data needs to have access to both the private-key and also the passphrase.


Creating Certificate / Key Pairs

There are a number of well documented methods of generating the necessary "Public-Certificate" / "Private-Key" pairs, however we will describe one of the better known methods, using the OpenSSL command line utilities.

Public-Certificate and Private-Key (without password):

Using the OpenSSL command line utility, the public/private key pair can be created without a password for the private-key as follows, using your own settings for those shown Use the OpenSSL site documentation as a reference.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -subj "/C=US/ST=CA/L=San Diego/O=MyCompany/OU=MySoftware/CN=MyCompany/emailAddress=support@mycompany.com" -keyout my_private.key -out my_cert.crt

This will produce the pair of files needed for encryption and decryption without a password.  Those files will be :

  • my_cert.crt         -  public certificate, used for encryption.  It is safe to give this out freely.
  • my_private.key  -  private key, used for decryption,. Does not require a passphrase during decryption.
Please also refer to the OpenSSL documentation as to what each parameter means, so that you fully understand how to create these key pairs correctly.

Public-Certificate and Private-Key (WITH password):

Using the OpenSSL command line utility, the public/private key pair can be created without a password for the private-key as follows, using your own settings for those shown Use the OpenSSL site documentation as a reference. Note the -passout pass:mypass option adds a password/passphrase ("mypass" in this case).

openssl req -x509 -days 365 -newkey rsa:2048 -passout pass:mypass -subj "/C=US/ST=CA/L=San Diego/O=MyCompany/OU=MySoftware/CN=MyCompany/emailAddress=support@mycompany.com" -keyout my_private.key -out my_cert.crt
  • my_cert.crt         -  public certificate, used for encryption.  It is safe to give this out freely.
  • my_private.key  -  private key, used for decryption. Requires a passphrase during decryption.

Please also refer to the OpenSSL documentation as to what each parameter means, so that you fully understand how to create these key pairs correctly.


Sharing Data with LumenVox

In order to share encrypted data with LumenVox, you must include a reference to the LumenVox public certificate in the list of certificates that are enabled for encryption as described in the Multiple Keys section above. This involves adding the LumenVox public certificate to the list of certificates configured in your LOGGING_ENCRYPTION_KEY setting in client_property.conf.

The LumenVox public certificate (lumenvox.crt) is included in the installation packages. On windows, the certificate is included in the Engine and SpeechTuner installations. The file can be found on disk at 
C:\Program Files\LumenVox\Engine\www\certs\lumenvox.crt or 
C:\Program Files\LumenVox\SpeechTuner\www\certs\lumenvox.crt.
On linux, the certificate is installed with the LumenVoxCore installation package and is found at /etc/lumenvox/www/certs/lumenvox.crt.

If you are using a public certificate of your own to perform data encryption, then you would simply add a reference to the LumenVox public certificate in your LOGGING_ENCRYPTION_KEY setting in client_property.conf to the end of the list  following a comma separator

For Example :

(Linux)
LOGGING_ENCRYPTION_KEY = /customer/cert/file.crt,/etc/lumenvox/www/certs/lumenvox.crt
 

(Windows)
LOGGING_ENCRYPTION_KEY = 
C:\certs\customer.crt,C:\Program Files\LumenVox\Engine\www\certs\lumenvox.crt


What Do These Files Look Like?

Here is a sample Public-Certificate file:


An example Private-Key file without password / passphrase:


An example Private-Key which requires a password / passphrase:


Note : The above example files are just samples and not the real LumenVox certificates or keys!