The basics of Data Encryption

First and foremost is the need to understand that data encryption can be extremely costly if not implemented properly. On rare occasions encrypted data can not be decrypted and is rendered useless. Worse case, your data is lost/not retrievable. This task must not be approached in a hap-hazard manner!
A very common example of encryption is authentication of passwords which can be rated by strength. Websites such as The Password Meter and Comparitech can help weigh the strength of passwords. Even though the actual value in the password field is not visible in any human readable form the field value can still be altered or deleted, so encryption is only part of the solution. The password must also be authenticated and protected from other forms of manipulation.
In order for an individual or an organization to be fully protected an overarching strategy needs to be implemented. The traditional methods of securing data based on limiting rights of users or groups is still valid but is only part of the total solution. The encryption strategy must include the local data center but also data being saved to media or transmitted via communication channels.
  • do not rely on application security measures, use the operating system methods as they are more reliable, for example use public authority *EXCLUDE for sensitive objects including programs
  • employ password system values
  • audit and limit the number of users with special authorities, *allobj, *secadm... etc.
  • audit and limit the number of users with remote access, ODBC, iSeries for windows... etc.
  • journal changes to key system and control files, audit changes
  • longer keys are safer than shorter key, destroy old keys
  • decryption periods are longer than encryption periods (days until expiration)
  • keystore owners user profiles should not be allowed to sign on to the system (profile expired, initial program *none... etc.)
  • keystore owners (creators) should have *all authority revoked and objects authority should be changed to *use for users
Detailing all of the different algorithms used in cryptography is beyond the scope of this article. The various methods should be carefully studied and understood before making a decision to ensure the choice fits your situation.
The most important element in the cryptography operation is the key. There may be multiple keys and some operations might include public and private keys, master keys, key encrypting keys, and many other types. The key should be created, stored, retrieved, and perhaps deleted such that no unauthorized user has access to it at any time. The stored key must have zero visibility. If stored in an object it is best to use object level security to protect that object.

If keys are to be generated in-house they should not be made up of words only but rather should contain a paraphrase that cannot be found in any dictionary so that hacking becomes much more difficult. When the key is created then it too should be encrypted and any new or changed key should be backed up immediately. For security purposes the key is backed up on different media than the encrypted data. IBM offers a general method of key management via Cryptographic Services which is part of the base i5/OS. Encrypting backup data is a nice update to BRMS in V6R1. There is a more complicated, more expensive, more thorough method called Common Cryptographic Architecture or CCA if the maximum amount of security is required. There are also third-party encryption solutions such as Crypto Complete.

There is also the need to ensure that the data is not compromised even though it was encrypted. You need to know that what was received is, in fact, unaltered and positively from the correct source. Digital signatures are often used for this purpose.
Aside from research and planning a strategy, probably the bulk of work in implementing encryption will stem from the simple fact that the encrypted field must be larger than its non-encrypted counter-part. This means either changing file layouts or creating extension files (what IBM calls "data normalization"). The process needs to begin in a testing environment temporarily keeping the old non-encrypted data intact. Of course applications will need to modified to use new layouts or extension files and then use encryption, possibly by call existing API's and handling keys.

Furthermore, there are various methods of applying encryption that must be understood. SQL, Cryptographic Services APIs, and Hardware encryption are your main choices here. There will be time required for the actual conversion to encrypted data. Then there is the question if your installation (and file layouts) will need to handle data decryption.
You should realize that encryption can also affect other applications such as change management, file editors, source debug, runqry, runsqlstm, SQL, Query, and any application that might not handle encrypted data. The need for data security and integrity should be becoming more and more apparent. Breaches can be costly and embarrassing to victims. We've all heard stories of credit card numbers missing by the thousands or tens of thousands.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For a more detailed discussion of security and encryption see the redbook; IBM System i Security: Protecting i5/OS Data with Encryption.   This is a large PDF so be patient - it takes a while to load.  This guide has detailed information about the various cryptographic methods as well as advice regarding implementation.