Summary: 

Some sites require data encryption for security reasons. This document outlines the mechanisms available for data encryption within a CA IDMS database.

Background: 

Data encryption is required at some sites for legal reasons; at other times it is necessary because of business requirements of the company.

Environment:  

When data encryption is required at a site, it is independent of the environment. It can be required and implemented in any operating system. 

Instructions:

For many sites, their need for encryption is addressed by using CA IDMS Presspack. This is aimed at data compression but it uses Huffman encoding techniques to completely encrypt the data. Presspack supports generic or customized Data Characteristics Table (DCT). Customized DCTs are created by sampling the rows of the data that you want to compress/encrypt. This creates a new DCT load module that can be secured so that only users with access to the data can see it. (If anyone tries to access the data through a subschema that includes the row, if they do not have the DCT access they will get a security violation.) Subschema security also applies.

Presspack can only encrypt data following the last byte of all control fields, e.g. sort field, index key etc. With that exception, the compression / encryption will apply to the whole record. The only place where non-encrypted data is held in memory is the working storage for the application. It is encrypted on the database file (and therefore also any backup tape), the database buffers and also the database journals.

In addition to Presspack, some sites use the Database Procedures IDMSCOMP & IDMSDCMP to compress and decompress their data, which also encyrpts the data to an extent. Because these do not use the Huffman encoding technique, some of the compressed data may be left 'as is' and thus be more easily interpreted compared to the same data compressed with Presspack. Compression using IDMSCOMP / DCMP is only done on the portion of the record which follows after the CONTROL LENGTH; the control length specification should include all KEYS (calc,sort,index) in the record. In that way, use of Presspack and IDMSCOMP.DCOM are similar in that neither will encrypt the key fields of a record.

At CA-World in 2008, a client gave a good presentation about encryption of CA-IDMS data using DB procedures that they created. A PDF of this presentation can be downloaded here: Encrypting CA IDMS Data.pdf.

Other sites also encrypt (not compress) key fields using database procedures of their own design. You may want to check the IDMS Community to see if anyone has routines or approaches they can share for doing this. If you decide to encrypt your key fields, there are a few considerations you should be aware of:

1. Encrypting a sortkey could alter sort sequence and affect applications in a negative way.
2. If encrypted fields are to be included in a sortkey, we recommend dropping the index, running the encryption routine to replace the old value with the encrypted value; and then rebuild the index. Calckeys will be more complex as it's highly likely that the encrypted values will target entirely new pages, resulting in massive calc overflows. You would need to plan on Unload/reload immediately after that conversion to avoid the Calc overflows.
3. If you implement a DB Procedure for encryption, when the procedure is called BEFORE STORE and BEFORE MODIFY the record address in the 5th parameter is where we will take the record data from when it is written to the database. You would also need to call the procedure BEFORE FIND. In the DB proc, you would need to check to see if the verb is 33 or 51 (the FIND...USING verbs). If it is, the procedure would need to go to the location of the USING field and encrypt it in order for these verbs to find the record in the index which should contain the encrypted values.

Internally, we do support password encryption for user signon. This is a one-way algorithm and we do not distribute information as to how this is accomplished. When a password is defined it is encrypted. If SIGNON is secured internally then when a user signs on and supplies a password, it is encrypted and compared to the stored encrypted pw in the USER record. There is no un-encryption algorithm.

Additional Information: 

As noted above, one user's approach to using DB Procedures to perform data encryption can be found here: Encrypting CA IDMS Data.pdf. 

Additional information about implementing data compression using CA IDMS Presspack, which uses HUffman encoding techniques to encrypt data, ca be found here: https://docops.ca.com/ca-idms/19/en/using/using-presspack