Encryption Key Management

ExtraView is a secure application and has been developed to adhere to the strictest standards.  Additional security is important and should be deployed by ensuring the environment within which ExtraView resides is secure, using firewalls and encryption of the network traffic with SSL, etc.

It is possible to protect sensitive data within the database using a further level of encryption.  This protects against your database from unauthorized access, and unauthorized users using SQL commands to extract data.  This encryption is provided for fields with a display type of text, and is applied on a field-by-field basis.  This can be used, for example, to provide added protection for fields such as social security numbers and bank account numbers.

Authorized users will still see data that is encrypted within the database in the normal way.  It is assumed that users will be educated on the sensitivity and privacy of data, and that the screens and reports they view may contain proprietary data that should not be stored with unauthorized personnel.

This feature is only available in the ExtraView Enterprise version.  To provide the security, secret keys (or passwords) are stored in what is termed a keystore, within ExtraView.  You may use a single key for all the fields you protect, or use different keys for different fields.  The keystore may also be used to store certificates, for example certificates that grant access to SAML authentication servers.

These keys must be stored safely by the administrator, and there is no way to ever retrieve a lost key.  This is critical to understand and neither the ExtraView application nor ExtraView Corporation personnel can ever retrieve a lost key.  It cannot be stressed too much how important it is to have a process to record the keys used, and to keep them safe.

Further, here are items that should be considered before implementing encrypted fields:

  • Only text fields that do not have data stored as yet may be encrypted
  • Once encrypted, you cannot revert a field to being non-encrypted
  • You cannot use an encrypted field as a filter in a query or report
  • Encrypted fields cannot be sorted within reports

The above limitations may be relaxed within future versions of the product.

There are 3 possibilities of how the secret keys may be used to unlock the data, dependent upon your requirements:

  1. The secret key(s) must be entered manually by the administrator on each and every occasion after starting the application.  This is accomplished by the administrator going to the Encryption Key Management utility and entering the passwords for each of the secret keys
  2. The passwords may be entered into the Configuration.properties file which is read by ExtraView upon startup of the application.  This is more convenient than entering the passwords manually, but not quite as secure.  Of course, the filesystem with the Configuration.properties (and other) files should be protected
  3. You can encrypt the entries within the Configuration.properties file using the technique described in the ENCRYPT_PROPERTIES section of the Installation & Configuration Guide.

Setting Up Encryption

  1. Enter the administrative utility, Encryption Key Management, on the Advanced administration tab
  2. Carefully read the directions, remembering lost keys can never be retrieved
  3. Click Add a new encrpytion key to the keystore
  4. Provide a fixed name for the key.  This follows the usual naming conventions of all ExtraView names
  5. Enter the secret key password
  6. Re-enter the secret key password
  7. Now, use the Data Dictionary to add the field whose contents you wish to encrypt.  It must have a display type of text, and you must select the option to Encrypt this Field.  Note that encrypted fields may not be used as filters, nor may they be made sortable fields
  8. You will be prompted for the secret key to use for the encryption.  Enter the password you entered into the keystore
  9. From this point, the field is configured like all other fields and may be placed on any applicable layout or report.

Unused keys may be deleted from the database, and the keys within the keystore may be updated by the administrator after providing the current key.

Recommendations

  • Only encrypt fields that contain sensitive data.  There is an overhead to encrypt and decrypt their contents and you do not want to impact performance negatively
  • Only provide multiple secret keys if different administrators each maintain the field contents that are encrypted within each field.  You do not want to create an excessive administrative burden
  • Again - make sure you keep the passwords safe.  ExtraView Corporation cannot retrieve lost passwords.  This is the essence of security, and there is no "back door" to work around this.

Certificate Storage for SAML Authentication

SAML authentication schemes typically require a certificate in a specific format known as PEM (Privacy Enhanced Mail).  The name is a bit of a misnomer as the certificates for SAML have no connection with email.  The format is a Base 64 encoded striing of characters which should be pasted into the Enter certificate PEM field.  If there is no entry in this field, the new entry you create for the key is added as a secret key only and is not used for SAML authentication.

The entry in the keystore should look like this:

  • Name for the key - this should be SPKey
  • Key password - this should be password
  • Certificate PEM - this is where you paste the certificate.  The certificate must conform to a specific format.  The following is an example displaying the necessary format (the certificate value is not real):

The action to save a certificate in this field builds the appropriate credentials for the SAML certificate.