Some sites require data encryption for security reasons. This document outlines the mechanisms available for data encryption within a CA IDMS database.
Data encryption is required at some sites for legal reasons; at other times it is necessary because of business requirements of the company.
When data encryption is required at a site, it is independent of the environment. It can be required and implemented in any operating system.
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:
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.
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