5 Myths About Encryption on IBM i

In version 6, IBM i introduced the capability to enact encryption across the entire disk drive. That means everything placed on the disk is first encrypted by the disk controller and then written out in that encrypted form. That happens seamlessly across the entire disk unit.

At first glance, this process appears very secure and gives a lot of IBM i pros the initial gut feeling that this is the answer to your encryption needs. One of the benefits is that disk encryption is extremely quick. Most IBM i Power Systems servers have crypto processors built into them or they have disk controller cards that are handling the encryption function at a hardware level, which is generally the fastest way to do any encryption and decryption functions.

A common question is whether encryption has an impact on system performance. Typically the answer is yes, the impact on performance is at least worthy of consideration. But when it comes down to encrypting at the hardware level—arguably the lowest level we can got to—the impact is negligible.

The other factor that bodes well for disk encryption is that the encryption is completely non-invasive. If we make changes to the application or to the database structure in order to accommodate some of the encrypted form, then that’s an invasive function. Most of us don’t want to do that. With full disk encryption, all of that is happening down in the disk controller. The application and the database have no interaction with or no visibility to the encryption going on behind the scenes.

Because of these factors, disk encryption seems plausible. The fact that it can be done seamlessly and quickly make disk encryption an appealing approach.

But we need to dig deeper.   

If you’re using internal disk (drives within the chassis of the server itself), full disk encryption has limited benefit. Yes, it’s fast and non-invasive. It will potentially get you the box checked for a compliance mandates that simply says you must encrypt data.

If, however, you’re using external disk—some type of storage area network (SAN)—where the physical drive units are in a different location from the disk controller, then full disk encryption is extremely beneficial. What happens is that the encryption travels down the wire. If someone intercepts that wire, everything that came out of the back of the box was in an encrypted form. If you have a server with the capability of encrypting disk and you don’t have to invest in anything, why not take advantage of this feature?

So, yes, full disk encryption has benefits. But is it the magic solution that meets all of our encryption needs? No. The encryption and decryption functions happen without any interaction with the application or the OS. Encryption happens any time a disk write happens and decryption happens any time a read occurs. The problem is that there’s no differentiation between people who are performing authorized functions (such as running the approved business applications, or doing an FTP or ODBC connection) and people who are performing unauthorized functions.

The data is fed in and out without any decision-making or conditions associated with the encryption. That means that if you have authorized access or unauthorized access, the operating system doesn’t care. It simply provides the clear text version of that data, regardless of the interface being used. It’s totally transparent. From a security standpoint, we want decisions to be made as to whether the user has access to the clear text version of that data, rather than just handing it to that user.

Full disk encryption has value, but it’s not the answer most organizations are looking for. If data protection is the reason why you’re considering encryption, full disk encryption does not provide all the benefits most IT pros want or expect.

If everything is encrypted, nothing is at risk, right? Not exactly.

If you’re a history buff, you may have heard of the Enigma Machine. It was heavily used during World War II by Germany for communication between troops. Everyone else was listening to the transmissions, but no one could understand them and the key changed every day.

Ultimately, human error is what allowed the Allies to break this encryption. They discovered that the same phrase was used consistently at the end of every message, and that gave the codebreaking team something to work back from. They had a pattern to look for. The repetition of a known phrase is what enabled the code to be broken.

Are there patterns in your data? Almost certainly. Encrypting everything actually weakens the protection you’re trying to achieve.

System performance is another factor to consider. Disk encryption is fast because it’s done at the hardware level. Most encryption is done using software, and there is a performance impact. Encrypting only sensitive data limits the performance impact to just the times when that data is read or accessed. Encrypting data that’s not actually sensitive impacts system performance, but without any actual security benefits.

So, what data should be protected?

• Anything confidential to the organization, its employees, and its customers
• Payment card data (credit card numbers)
• Personally identifiable information (PII) data, such as Social Security numbers and birth dates
• Protected health information (PHI) data
• Bank account numbers
• User IDs and passwords
• PINs
• Payroll information (e.g. wages)
• Driver’s license numbers
• Financial data
• Trade secrets (e.g. product formulas)

Focus your attention on protecting sensitive data, so you can optimize your environment and ensure it’s as seamless as it can possibly be.

There are some core cybersecurity rules designed to help organizations protect their data. One is the directive to protect sensitive data. Another one, included in a few compliance mandates, is the requirement to use strong encryption. The problem is that the definition of strong encryption changes over time. What was impenetrable decades ago can now be broken in a matter of hours. That’s why mandates don’t name a specific algorithm.

The strength of the encryption is influenced by:

• The choice of algorithm
• The length of the key
• The secrecy of the key

Use industry-standard encryption protocols. AES is one example. Make sure whatever algorithm you choose is based on sound mathematical knowledge. Utilize sufficiently strong keys and put the appropriate protections around those keys.

Regulations increasingly call for crypto-based technology, whether that’s tokenization or encryption. The theory is that if your organization is breached and the data is unreadable, did any harm actually occur?

Encryption can remove some—not all—of the reporting requirements if a data breach occurs. GDPR is very clear that encryption is recommended and can alleviate some reporting requirements in the event of a breach. But it doesn’t remove the requirement to investigate a breach, document what occurred, and report it to the oversight organization.

If you’re doing encryption to meet a regulatory mandate, look at the overall sense of the regulation along with the details. Make sure your encryption process actually satisfies the law—the nuances are important.

In version 7.1, IBM i introduced Field Procedures: a non-invasive way to encrypt the database. It’s also non-invasive to many applications. Field Procedures are integrated with all OS functions and they can be controlled programmatically, so you can mask data. Masking prevents users from seeing data that they’re not authorized to see, but it won’t stop them from seeing data that they’re supposed to see. There are performance considerations with field procedures, but you get controls without having to make major application changes, which can be a very important benefit.

Although the theory behind modern encryption is quite complex, the implementation on IBM i doesn’t have to be.

Now that we’ve cut through the myths, it’s clear that data encryption it is an important security control that can drastically improve your security posture. Powertech Encryption for IBM i is an easy-to-implement solution that provides a high level of protection.

If you want to learn more about how encryption works on IBM i, check out our guide to protecting your database with encryption >