Data Encryption

Reality Data Encryption makes your data more secure and also allows you to control which users can access particular files. Each encrypted file has an associated key that is stored in a centrally located file - users are granted access to the file by being given permission to use that key. The encryption key file is itself protected by a database administration key that is only accessible to the users of the database. You can use either the DES:CBC or the Triple DES algorithm to encrypt your data.

Encryption is transparent to the users that are granted access to a file - they do not have to manually decrypt an encrypted file before they can use it, but can view, change and delete the file in the normal way.

Data saved to tape can also be encrypted - the majority of save and restore commands do not decrypt encrypted data. Tape devices can be configured to encrypt data before saving.

The DataBasic ENCRYPT and DECRYPT functions also allow encryption using DES:CBC or the Triple DES, with keys either from the encryption key file or specified explicitly.

Configuring Reality to use Data Encryption

Before you can use encryption on a Reality database, you must create an administration key to protect your key file (the REK file in the SYSFILES account). This is done using the SET-ADMIN-KEY TCL command - you must supply a 16-character encryption key that will be saved in encrypted form in a host file called adminkey in the database configs directory. The administration key can only be used on the host system on which it has been created.

Caution

Once you have encrypted your data you must not change the administration key. If you do, you will not be able to read the keys in the REK file and will therefore not be able to access your encrypted files.

Users that need access to encrypted Reality files must be given read access to the administration key file. It is recommended that all other users should be prevented from accessing this file.

Note

If you prefer, you can save the administration key to a different host file by setting the REALADMINKEY environment variable. If you do this, all users that use encrypted files must have access to REALADMINKEY - on UNIX this can be done by defining it in /etc/profile, while on Windows it must be defined as a system variable.

Caution

Depending on how you set REALADMINKEY, all databases on that host may have to use the same administration key. Be careful not to overwrite a key set from another database.

If you are using encrypted files on FailSafe, both databases must have the same set of encryption keys. However, the administration keys that protect them need not be the same.

Encryption Keys

Once you have created an administration key for your database, you can create the keys that you will use to encrypt your files. This is done using SSM Option 5 - Encryption Key Maintenance - the keys are stored as items in the REK file. You can create as many keys as you need using either the DES:CBC or Triple DES algorithm for each (Triple DES is the more secure). You specify the item-id of the key to use when you create an encrypted file, but do not give the actual key.

Notes

  • Any user who is logged on to the SYSMAN account can create, change and delete REK file items.

  • Your REK file should be saved separately from your database (preferably in a secure off-site location) - see Copying Encrypted Data to another Host for details.

Caution

If you change the encryption key stored in a REK file item, you will no longer be able to access any files encrypted using that item.

Encrypted Files

Once you have created your encryption key items, you can create encrypted files to hold your data. This is done by using CREATE-FILE with the (C option. You will be prompted for the id of an encryption key. For example:

:CREATE-FILE MYENCFILE (C
Enter Reality encryption key:MYENCKEY

[417] File 'MYENCFILE' created.
D code =DL, modulo = 1, separ = 1
[417] File 'MYENCFILE' created.
D code =DL, modulo = 1, separ = 1

If you want to encrypt an existing file, you must create a new encrypted file and copy the contents of the existing file into it (remember to copy the dictionary of the file separately). You can then delete the existing file and rename the new one to have the same name as the deleted file. For example, to encrypt the data in the file CUSTOMERS:

:CREATE-FILE TEMP (C
Enter Reality encryption key:MYENCKEY

[417] File 'TEMP' created.
D code =DL, modulo = 1, separ = 1
[417] File 'TEMP' created.
D code =DL, modulo = 1, separ = 1
:COPY CUSTOMERS *
TO:(TEMP

13 items copied.
:COPY DICT CUSTOMERS *
TO:(DICT TEMP

8 items copied.
:DELETE-FILE CUSTOMERS

:RENAME-FILE TEMP
TO:CUSTOMERS

The file that formerly resided in the "ACCOUNTS" account
and was called "TEMP"
now resides in the "ACCOUNTS" account
and is called "CUSTOMERS"

Note

The ENCRYPT-SET command allow you set "encryption mode" with a particular key id. You do not then have to specify the (C option when running CREATE-FILE.

Giving Users Access to Encrypted Files

When you have encrypted your data, your users will no longer be able to access the data, so you will need to grant them access. This is done by modifying their security profiles to include the ids of the appropriate encryption keys. Use SSM Option 3 (Define Security Profiles) and for each security profile, set option 25 (Reality Encryption Keys) to the item-ids of the required encryption keys from the REK file. Once this has been done, provided their security profile contains the correct key, they will be able to access encrypted files in the same way as before encryption. Note, however, that if they attempt to read an item from a file for which they do not have the key, only a string of hashes will be returned. Similarly, it they attempt to write to a file to which they do not have the key, an error message will be displayed and the data will remain unchanged.

Notes:

  • Encrypted files and the items they contain cannot be deleted unless the user's security profile gives them access to the appropriate REK file item.
  • Any user who is logged on to the SYSMAN account has unrestricted access to encrypted files anywhere in the database.

Copying Encrypted Data to another Host

The Reality save commands do not decrypt encrypted data before saving - if you use these commands to copy or move encrypted files from one database to another, you must have the correct REK file so that your users can access the encrypted data. However, because the administration key that protects the REK file can only be used on the host system on which it has been created, you cannot simply transfer this file from a database on one host system to a database on another.

Two TCL commands, SAVE-REK and LOAD-REK, are provided that make it possible to transfer a REK file from one host to another. SAVE-REK decrypts the REK file and then re-encrypts it using a temporary key that you supply; the result is saved to the file you specify. LOAD-REK does the reverse - it decrypts the file you specify using the temporary key with which it was encrypted and saves the result in the REK file, using the administration key to encrypt it.

Caution

Existing keys with the same ids will be overwritten.

Note that your temporary REK file should be copied to the new host separately from the encrypted data (you could save to a binary DIR-VIEW to create a host file, or use the T-DUMP TCL command to save the Reality file). You must load your copy of the REK file after you have restored the data, overwriting the saved copy, if any:

Notes