Rss Categories

Key Management Information

Reference Number: AA-02268 Views: 214 0 Rating/ Voters

LumenVox Password Reset solution is fully FIPS 140-2 Compliant, meaning it supports a very high level of data security encryption to protect user's information that may be used by the system.  Note that LumenVox does not use any third party components for encryption, thus relying on algorithms available to the operating system in order to remain FIPS compliant.

The key management mechanism used for encryption is described in this article.

Level 1 – The Installation key

At the highest level resides an installation key which is a strong (RSA- 4096) asymmetric key. This key also happens to be used as part of our licensing mechanism. The private key portion can be marked as not exportable and is linked to the license which is generated on the application server itself. When LumenVox generates the license request, a private key is also generated with this request and this key stays within the realm of the customer premises (LumenVox does not need to have this key and cannot decrypt any data for the customer unless to customer chooses to share this key with us.) 

This private key is installed with the certificate in the Windows certificate store of the application server.


Note that the loss of this private key will render all encrypted data on the system unusable, so you should verify that this key is stored in a secure location and loss should be avoided at all costs.


Also note that for multi-server solutions or migration from one environment to another we will need to export the private key and import it to the second server's license file, since both machines need to be using the same private key.

Level 2 – The master key(s)

A Master Key is generated by the system during the initial startup of the application and this Master Key value is signed with the Installation Private Key to prevent key replacement, further the key contents are also encrypted using the Level 1 (Installation) Key, which is described above. This signing is done using a SHA-1 hashing algorithm. 

Master Keys use an Advanced Encryption algorithm (AES-256) and are only used to encrypt / decrypt Working Keys, that are stored in the database and are described below.

Note that Master Keys can be disabled by an administrator for any reason, rendering them unusable. This might be done if it becomes necessary to replace or retire a Master Key for any reason or if periodic cycling rotation of keys is desired. Re-encryption of data using active keys is needed if a key is marked as removed.

Level 3 – The working keys

Working Keys are used to store end-user encrypted data while the application is running. These use a Triple-DES algorithm and will be encrypted using the Master Key (see layer 2 above) and will stored in encrypted form within the database. 

Each system area has a different set of working keys (e.g. models, features, identities, etc.). All encryption operations include (SHA-1) hashing which binds encrypted data with logical entities (e.g. model are linked with claimant symbol, profile symbol, etc.), to ensure that encrypted data belonging to one entity cannot be used with any other (the key used for Hashing / Signing is the Master Key (described above).

These Working Keys are the ones that will be used to encrypt Technical credentials, Voice Models and any other encryption-worthy data.

Modifying Cryptographic Providers

The above description of key utilization is the default setup up of our Cryptographic functionality.

We can also provision the security package differently if AES or 3DES are not wanted by the customer for some reason. Additional time and resources are needed to configure this custom cryptographic configuration, which is typically around 2 working days. Available options include having Master and Working Keys both be AES, 3DES, AES/3DES or 3DES/AES. See your LumenVox Account Manager for specific details and quotation if this is something that you require.