It’s true that the only real encryption is end-to-end encryption. If the private key is anywhere other than the endpoint, someone can filch it without the endpoint owner knowing. But the interesting thing is that an encrypted packet can be treated just like any other packet: a string of bits to be delivered onward. And so, if multiple end-to-end encryption regimes are in operation, they don’t interfere with each other. I don’t care what’s in your packet; my job is just to deliver it to the other side of my world in the same condition it entered. And you don’t care what I do with it in the meantime. The only question is cost. Cost is mostly realized in packet delay. If each regime adds a small but positive cost, then perhaps all that encryption isn’t worth it.
And there are further complications. Deciding which data needs to be encrypted isn’t easy. Only certain fields (e.g., Social Security number) may be legally required to be safeguarded. But isolating them at the application level demands a degree of format compatibility and application awareness. So even once determined, these fields are not easy to find. And large corporations have thousands of such applications.
IBM’s Mike Jordan, a Distinguished Engineer on the company’s security team, described one customer with 18,000 Cobol applications. He estimated that it would take 50 hours’ work on each one to find, isolate, and provision for encrypting the critical data elements. Using a measure of $150 per hour as an estimate of programmer cost, a granular solution in this case would cost $135 million. This firm and other IBM customers began to raise a hue and cry about this unanticipated but required material outlay.
This is where “pervasive” encryption comes in. IBM engineered a pervasive encryption layer into its latest generation of mainframes, the z14 family. Pervasive encryption satisfies legal data compliance requirements without the customer’s having to do a lot of data classification exercises or expensive application modification. Because of the urgency of this requirement and the looming cost of compliance, customers approached IBM some time ago looking for a way out. Pervasive encryption was the company’s response.
Pervasive encryption addresses both data at rest and in flight. While z/OS data-set and Linux file and volume encryption are focused on data at rest, all network traffic coming into and out of the mainframe is also encrypted. An organization wants be able to point to its encryption regime for compliance purposes. Look, you see that data resting over there at that disk address? It’s encrypted. Nobody can do anything with that string of bits if they snag it. All quiet on the Western Front.
But as noted earlier, the encryption regime that kicks in during transport doesn’t care what’s in the bit string at rest. It does its own untangling before delivery at the other end. Thus, pervasive encryption works hand in hand with transport and other encryption regimes.
The nut of pervasive computing is that it’s fast and cheap and easily applied in bulk. For protection of master keys, crypto acceleration functions on the processor itself are tightly coupled with a crypto hardware accelerator card. Bulk encryption is handled by a 256-bit symmetric AES encryption algorithm. Thus, with a nominal computing overhead cost, large enterprise customers can protect their data against attack. Since this encryption is running in an enterprise environment, all keys are owned and managed by the designated authority. The symmetric algorithm is applied to 4 kilobyte blocks for best performance, but block size is variable.
IBM already has a number of customers implementing pervasive encryption.
A U.S.-based credit card company, after a review of a competitive enterprise-wide alternative, found that processor overhead for encryption was almost 100%. By moving from application encryption on distributed platforms to pervasive encryption on a mainframe, the company reduced compute overhead to a fraction of that. The firm still uses application encryption in exceptional cases, but is otherwise cutting over entirely to pervasive encryption.
A French bank, subject to European data protection rules, needed to prepare for mandates set to take effect in May 2018. Already an IBM Z customer, the bank chose to meet this tight timeline with pervasive encryption deployed on new z14s.
A North American regional bank found during an audit that, even though it was using full-disk encryption for data at rest, the data wasn’t always properly isolated between production and development environments. The bank now plans to use pervasive encryption on a z14 with z/OS on top of full-disk encryption to plug this potential leak.
Pervasive encryption fits in the hierarchy of layers on which data at rest can be encrypted above full-drive encryption and below database encryption, which is itself below application encryption. The lower in the stack the cheaper and easier to manage. The higher, the more complex and the greater the degree of security control.
Enterprises would be acting rationally if they saved the higher levels for the most sensitive data and push the rest down as low as possible.
