Encryption Options on IBM i

On IBM i the key feature of the platform since day one has been Single Level Storage. This feature means that no one knows if the data is in memory or on disk — it’s just considered one large address space. This also means it is impossible to know exactly where on what disk the data is, assuming it has even been flushed to disk. When IBM i writes out data from memory onto disk it is indeed spread over all disk drives. This is why encryption to date has not really been a big requirement. Someone could remove a disk drive from IBM i and there is no way to determine what is on the drive and if data is inspected at a block level, no guarantee as to what data they have or how much of it.

With the increased number of ransomware and malware attacks hitting computer systems both for business and end-users, many shops are looking at encryption to protect their data. On IBM i encryption can be done using a variety of techniques, depending on the business need or audit requirements. If you just need the auditor checkmark to be “Yes we encrypt”, it can be done through tape encryption via hardware, or BRMS or using VTLs for backups. If you need encryption at rest, it is a little more difficult. Typically, encryption at the hardware level is through a SAN or IASPs on IBM i, while software encryption can be done via user exits or third-party tools.

ENCRYPTION ON IBM i

There are 5 ways to do data encryption on IBM i — here’s a summary of the pros & cons for each method, explained in more detail below:

OVERVIEW SUMMARY

EXTERNAL STORAGE-BASED SAN

Using a SAN connected to IBM i that has data at rest encryption. These would include the IBM DS8000 or Storwize SANs connected to IBM i.

PROS

• Everything is done at the hardware level, no CPU impact on IBM i

CONS

• SAN Expertise is needed to install and configure the storage
• Customers currently using internal disk need to replace their storage.
• For some customers, SAN-based storage may be more expensive

ASP BASED

With the launch of IBM i 6.1 in 2008, IBM added disk encryption through the new ASP-level encryption feature. This function, which is activated by selecting Option 45 – Encrypted ASP Enablement, allows IBM i users to encrypt all the data stored in a disk pool, or an auxiliary storage pool (ASP), as well as independent auxiliary storage pools (iASPs). IBM added the capability to turn encryption on and off for disk pools with IBM i 7.1.

PROS

• This encryption technique works with external storage arrays as well as internal disk, and also works with IBM’s iASP-based high availability setups (i.e. PowerHA).
• This ASP level disk encryption protects data from several threats:
• Protects data transmission to and from the disk drive (important in a SAN environment).
• Protects data transmission in the cross-site mirroring environment when the data being mirrored is on an encrypted independent disk pool.
• Protects data in the case of theft of the disk drive.

CONS

• The issue with this option is only user ASPs can be encrypted (i.e. only ASPs 2-32) not the system ASP. Disk encryption can be used to encrypt existing disk pools or independent disk pools.
• Migration of data from the system ASP to an encrypted ASP is done with save and restore. Some additional temporary storage may be needed to migrate the data, thus additional costs.
• Starting disk encryption on an existing disk pool might take an extended amount of time to encrypt the data in the disk pool, potentially affecting system performance.
• Once the disk pool is set up to use encryption, you can expect an increase in CPU consumption and additional memory requirements, but with proper planning, you should be able to achieve the same performance when encrypting your data as you had without encryption.

SOFTWARE-BASED ENCRYPTION

at the DB2 level. This uses the DB2 Field Procedure that debuted with IBM i 7.1 in 2010. The “FieldProc” was a game-changer for encryption because it no longer required developers to make extensive changes in their code, thereby opening up encryption to a large class of customers running older applications. The FieldProc has also been utilized by third-party software providers, including Linoma Software (now HelpSystems), Townsend Security Solutions, Enforcive (now Precisely), and most recently Raz-Lee Software. These vendors have updated their encryption software to support the DB2 FieldProc interface, which further reduces the amount of technical expertise required to use it. This is a good option for those clients that don’t want to invest in writing their own Fieldproc programs. All that’s required is registering the FieldProc program object…for those columns containing sensitive data. Any type of encoding can be performed by a FieldProc program, but IBM expects AES to be the most common.

PROS:

• Vendor supported, and easy to implement with no database changes
• Fields can be masked, tokenized or hidden instead of doing the entire file
• Protects data from internal users and network hackers

CONS

• Requires purchase of third party software and learning curve
• The downsides are that it requires some analysis to determine what files and fields should be encrypted. It is in essence masking fields to prevent them from being seen but can come with some heavy performance impacts.
• The native AES encryption software libraries provided in the operating system may not provide an adequate level of performance. It is important to assess the size of your protected databases and the nature of batch operations that require access to unencrypted data to avoid negative impacts to both interactive and batch applications.

HARDWARE-BASED

Using a hardware device like a 4765 Cryptographic Co-Processor or a PCIe-based processor like a 4807-4809 processor combined with the 5770-CYS licensed program product.

PROS

• This has the advantage of doing everything at the HW level and thus reduces resources on the CPU.

CONS

• While the hardware can alleviate the inevitable processing hit of encrypting and decrypting data, it requires the setup and management of the encryption using the software.

SOFTWARE APIs

Through software APIs. The main software-based encryption offering in use from IBM today is the Cryptographic Services APIs, which debuted with OS/400 V5R2. The Cryptographic Services APIs provide the capability for programmers working in high-level languages to access a variety of encryption-related tasks and workflows in the IBM i environment. It includes a set of APIs, including the core encryption and decryption APIs, authentication APIs, key generation APIs, and key management APIs.

PROS

• The Cryptographic Services APIs are very powerful
• The Cryptographic Services APIs support a variety of cryptographic libraries, including the 256-bit Advanced Encryption Standard (AES-256), which is considered the gold standard in security today, as well as older ones like 3DES that are no longer considered secure. It also supports an array of hashing algorithms like SHA-256, key exchange algorithms like Diffie-Hellman, and pseudo-random-number and key-generation algorithms.

CONS

• Working with them requires technical expertise that is beyond the capabilities of many IBM i shops.

CONCLUSION

To summarize, when most IBM i customers start to investigate data encryption at rest, it turns out they are better off tightening up their security on IBM i, through a security assessment and third-party tools from vendors like Precisely and Help Systems that can help set security policies, report on any issues and fix any exposures as well as products that can monitor network access through exit programs. Our Managed Security Services is also a nice option.

If the customer is only interested in encrypting their backups, that can be done through tape drives or through VTLs.

If you need support in protecting your data, then reach out to Mid-Range, a trusted IBM Gold Business Partner, to discuss your needs.