OpenInsight Data Encryption at REST
OpenInsight incorporates a new encryption service that system administrators can deploy to encrypt (on a field by field level) data in OpenInsight. The data will be encrypted at REST (Representational State Transfer) using industry standard encryption routines. Clients and the encryption service use the Windows Communication Foundation (WCF) to communicate, thus allowing the data to be encrypted in transit. Through the use of an Encryption Server (normally, but not necessarily, the same machine as the Universal Driver server), each OpenInsight workstation seamlessly and securely encrypts data for storage when written into an encrypted volume.
The metadata and actual table contents are stored on the encryption server using an AES encryption algorithm with a key size of 256 and two key iterations. For more information on this type of encryption see:
http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Configuration of the Encryption Server
One or more Windows Groups are assigned to one or more Encryption Server Roles provided with the Encryption Server. The people who can assign groups to the other roles must be members of the Role Manager groups. Members of the groups in the Server Manager roles can change the encryption settings on the server. Table Manager groups contain the people who can define or change the encryption settings on tables. Members of the groups that are in the Assign Impersonators role can programmatically set which group they wish to impersonate.
Impersonators are used when multiple different permissions are required, but all users log into Windows as the same user (e.g. the OpenInsight for Web user). Members of the groups that are in the Data Access roles are allowed to access the encryption system. Any users who are not members of these groups will not be able to connect to the encryption server.
Different Types of Encrypted Volumes: Site-specific and PASS
There are two different types of encrypted volumes. A normal Revelation Data Encryption at REST (RTIDER) is a site-specific volume that uses encryption keys which are maintained by the Encryption Server. All workstations accessing this Encryption Server can, with proper permissions, access the data. However, the tables contained in these volumes cannot be used by any other system running its own Encryption Server.
Alternatively, a volume can be defined as an RTIDER PASS (Password Authenticated Single Session) volume. To access tables in a PASS volume, the user must enter the required passphrases during table attachment. The PASS volume can be moved among different Encryption Server systems, and is thus suitable for transporting data either temporarily (for example, when copying tables between fixed systems) or permanently (for example, putting such tables on a thumb drive).
Creating a Site-specific Volume
Before encrypted tables can be created, an encrypted volume must first be defined. For a normal RTIDER site-specific volume, the CREATE_VOLUME procedure is used, with additional encryption parameters passed in as part of the "control_location" parameter:
Create_Volume( volume_name , filing_system, location, control_location, status)
The volume_name is the name of the new volume to create; the filing_system must be "RTP57E" for an encrypted volume; the location is the physical Windows directory for this volume; and the control_location contains the encryption details, in a @VM delimited string:
server_address : @VM : server_port : @VM : show_protected
The server_address is the IP address of the Encryption Server. The server_port is the port number that the Encryption Server service is "listening" on. A show_protected value of 0 indicates that encrypted fields should be blanked-out for users who do not have permissions to decrypt those fields. A value of 1 will display them in their encrypted format to those same users (Fig. 1).
Fig. 1
Creating a PASS Volume
To create a PASS volume, you must use the CREATE_VOLUME_PASS procedure:
Create_Volume_Pass( volume_name, location, control_location, passphrase, initVector, status)
The volume_name, location, and control_location are defined as above. The passphrase and initVector are the unique pieces that will be used to encrypt the information in this volume. The passphrase and the initVector are both user-defined strings or words; they should be unique to each PASS volume, but may be anything that is both memorable and easy to keep secret.
Note that, since PASS volumes require the passphrase and initVector to be specified each time they are initially accessed, you should NOT add tables (files) in the PASS volume(s) to your database definition. Instead, you must always run ATTACH_TABLE_PASS to attach, on a per-session basis , the tables in the PASS volume (Fig. 2):
Attach_Table_PASS( volume_pointer_name, tablelist, database, passphrase, initVector, status)
Fig. 2
Creating Encrypted Tables (Files)
Tables in the encrypted volume can be created using the CREATE_TABLE procedure, which has now been extended to include an additional parameter:
Create_Table(locationlist, tablename, dictflag, databaseID, tableattributeslist, protectflag, unused, unused, encryptInfo)
The encryptInfo parameter defines which fields in the table should be encrypted, which groups should be able to access the data in the table, and how keys should be processed. This parameter is an @FM delimited string containing, in order:
- list_of_fields
- list_of_groups
- error flag
- key part flag
Field 1 (list_of_fields) contains a list of which fields should be encrypted. This list is comma-delimited, and may indicate the keyfield (0), a part of the key (0*<keypart> for example: 0*1), individual fields (by number), or indicate all fields, including the key field (-1). All (-1) is obviously exclusive. You can list individual fields "0,1,3,4", or "-1", but you cannot mix the two.
Field 2 (list_of_groups) defines which Windows groups should have access to each of the encrypted fields. This list is in the format <fieldnumber>: <groupname> {; <groupname>;<groupname>}{,<fieldnumber>...}. For each field that may be encrypted (as defined in the list_of_fields), you may specify one or more Windows groups that can access that fields' information. As above, the field number may contain "0", "0*<keypart>", field numbers, or "-1". The group names can also be "*" to indicate "all valid Windows users in this domain." An example of the list_of_groups may be "0:inventory;acctg,1:*,3:acctg,4:inventory". To cover everything for everyone use "-1:*".
Field 3: If a user attempts to update a record for which he/she does not have full permissions, the Encryption Server can either "merge" the original record's fields with the updated data, or generate an error. If field 3 (error flag) is set to "1", then an error is returned; if set to "0", then the modified data is merged with the protected fields.
If a key contains multiple parts (separated by the key delimiter "*"), it can be encrypted as a single piece of information, or each key part can be encrypted separately. If field 4 (key part flag) is set to "1", then each key part is encrypted separately; if set to "0", the entire key is treated as a single string, and the key delimiters are ignored during the encryption process.
Please note that it is specifically allowed to create a table with no encryption information in an encrypted volume. Simply pass an empty string ("") as the encryptInfo parameter. If instead you wish to create an encrypted table with the default settings, pass in a parameter with 4 fields, each of which are the empty string ("") (Fig. 3, Fig. 4, Fig.5).
Fig. 3 Choose your level of encryption
Fig. 4 Select the columns (fields) which will be encrypted
Fig. 5 Users who are not members of this group cannot view the FAX data
