Removing Barriers to Pervasive Encryption on IBM Z
Fear of the unknown need not be a barrier to adopting good data security practices with pervasive encryption as a cornerstone.
By Mark Moore01/03/2019
IBM Crypto Express Card
I lose my car keys all the time, but I’m afraid of losing my crypto keys. Fortunately, there are several things that can prevent this. Let’s take the master key for example. The z/OS facility for managing the operational keys for data set encryption is Integrated Cryptographic Services Facility (ICSF).
It’s recommended that operational keys be “secure keys.” Secure keys are operational keys that are encrypted using a master key present in a hardware security module (HSM) like IBM's Crypto Express card. A bad actor with a copy of a data set and its secure key cannot read the data because it does not have the master key to decrypt the secure key. The FIPS 140-2 level 4 design and construction of the Crypto Express card ensure that the master key cannot be extracted.
There are redundant Crypto Express cards to prevent loss due to failure. There are multiple slots for each master key—new, current and old. Key “ceremonies” ensure the key lifecycle is implemented properly. Multiple key custodians can be used so that no one person has the whole master key and each part of the key is backed up.
In larger environments, a Trusted Key Entry (TKE) workstation helps to manage multiple Crypto Express cards and domains. Enterprise Key Management Foundation (EKMF) can provide enterprise-wide operational key and certificate management across a variety of platforms.
You might still be asking, how can I know in advance how encryption will affect performance over time? What about initial encryption of my data? Based on a survey of customer data, a rough rule of thumb for the overhead incurred by data set encryption is +2.6 percent CPU. However, it’s possible to compute the overhead for a particular data set in advance.
The IBM Z Batch Network Analyzer (zBNA) is a PC-based tool that can analyze metrics from a data set at work to determine the performance impact of encrypting that data set. It can also compute the potential performance improvement that would result from a hardware upgrade. Finally, zBNA identifies good candidates for compression with IBM Z Data Compression (zEDC) for z/OS.
When an existing data set is encrypted, its data will have to be read in its initial, unencrypted state and written as encrypted. Benchmarking performed by IBM shows that data can be encrypted at 9.25 GB/s per z14 core. To calculate a z14’s capacity based on installed MIPS, that works out to approximately 198 MIPS per GB/s. With those numbers in mind, a rough calculation can be done to determine the time and resources required to encrypt data sets. If there isn’t sufficient time to perform the encryption without affecting the 4-hour rolling average, additional hardware can be added temporarily.
Compression and Network Traffic
You might be wondering why I keep mentioning compression. Encrypted data cannot be compressed. If compression implemented in storage devices is being used, it will stop working. Data must be compressed on the host before being encrypted. zEDC can be used for this. The work of compression is offloaded to an add-on card. As a bonus, after compression there’s less data to encrypt, reducing encryption time.
As for data in flight, we need a complete picture of the network traffic. For network traffic, z/OS Encryption Readiness Technology (zERT) provides a single source of information to determine what traffic is cryptographically protected and what is not. For the traffic that is cryptographically protected, the attributes of that protection can be determined.
The important thing is to get started. Start small, with a proof of concept. Build experience and confidence. Seek advice. Remember that you’re not the first to do this. With that in mind, IBM has a great Redbook to help you get started with data set encryption.
Mark A. Moore is a software architect in IBM's IT Economics and Research team, focusing on data security.
See more by Mark Moore