HelpSystems Blog

Using Field Procedures for IBM i Encryption

Encryption is a hot topic for cybersecurity, no matter what platform you're using. Recently, Robin Tatam has fielded quite a few questions about how to encrypt IBM i data. In the quick video below, he outlines your options.


If you've ever done or tried to do encryption on IBM i, you've probably considered full-disk encryption. It seems really easy—kind of a silver bullet. But the reality is, full-disk encryption really doesn't solve the dilemma of protecting data from unauthorized access.

That's because any request to access the database, whether it's FTP or RPG programs, will always get that data back in the clear. It doesn't really protect us from anything other than the drive being pulled out of the system. There's also some IBM supplied APIs that allow us to do encryption, but they're quite complex to use and they require us to go through an application and in essence embed the calls to those APIs throughout the app.

Now, in version 7.1 of the IBM i operating system, IBM introduced a capability known as field procedures, also called FieldProcs, that allow us to do encryption in a much easier fashion.

Now, what we've draw up here is just an example of where we have data that maybe is entered onto a screen in an application. When that data is written to the database, it's automatically encrypted by the database manager. The field procedure itself is really just an enabler. You still have to write those field procedures or purchase them. But in essence, it's eliminating two massive requirements that were there previously.

One requirement is that you have to modify the database to support encrypted data format. It's typically a longer field. It's alphanumeric, which, if your original field was numeric, was challenging. In this case, with field procedures we don't have to actually make a change to the database. It's all handled automatically behind the scenes by the operating system.

That's huge because it can eliminate having to change the database many times. The field procedure then actually handles the encryption-decryption function. When the data comes into the database and is encrypted, we now have the option of selectively decrypting that information based on who the user is or what circumstances they're activating or accessing that data.

In that case, we now have the ability to pull that data back and potentially bring it back in a masked view. Maybe we see the last four digits of the social security number or the credit card number. We also potentially have the ability to pull it back in a full clear text view.

If you're not even authorized at all, of course you're going to get garbage that you can't read. That helps offset some of the risk associated with people accessing the database without permission, as in the case of a data breach. Field procedures enable us to do encryption with minimal work and often without any work at all, even if you don't own the source code to your application.

If you're interested in learning more about the field procedure approach, let us know. We have a phenomenal tool called Crypto Complete that allows us to, in essence, provide you with pre-written field procedures, so you don't have to do any of that. It's all handled automatically.

Hopefully that gives you a little bit of insight into encryption at a database level. If you have any questions let us know, otherwise we'll see you next time. 


Find Database Fields that Need Encryption

Before you encrypt IBM i data, you need to identify the database fields that contain sensitive data, such as Social Security or credit card numbers. Download our free tool to find those fields.