IBM Destination Z - Group home

Why We Need Pervasive Encryption

By Destination Z posted Mon December 23, 2019 03:25 PM


Since 2016, IBM’s z14 processors have offered pervasive encryption. I thought it would be interesting to look at why we need it, what it is and how it works with CICS and IMS.

The nightmare scenario for any company is a data breach and the negative publicity that goes with that. In 2018 a report by Ponemon Institute, sponsored by IBM, put the average cost of a data breach at around $3.9 million.

The other big worry for an organization is falling foul of compliance regulations. For example, non-compliance with the EU’s GDPR (General Data Protection Regulation) can result in administrative fines of up to 4 percent of an organization’s annual global turnover or €20 million—whichever is greater.

That makes data protection and compliance business imperatives. Figures suggest that there’s a 26 percent likelihood of an organization having a data breach in the next 24 months. And of the 9 billion records breached since 2013, only 4 percent were encrypted. In 2016, the average time before a breach was discovered was 191 days. In terms of data breaches, “It’s no longer a matter of if, but when.”

What Is Pervasive Encryption?

Many are already familiar with the idea of selective encryption. This is where specific fields and data are encrypted, and often means that applications need to be modified. It also comes at a cost because skilled people are needed to create and maintain the encryption, and there can be a cost in terms of the resources needed.

Pervasive encryption not only provides encryption without needing to modify applications, it can extend beyond specific fields and apply to inflight data as well as data at rest. And this also makes complying with regulations easier. In more detail, users can have full disk and tape encryption, providing protection against intrusion, tamper or removal of physical infrastructure. Pervasive encryption includes capabilities such as disk and tape encryption, file and data set encryption, database encryption, and application encryption.

File or data set encryption, which is managed through z/OS, provides simple policy controls that allow clients to protect data in mission critical databases including Db2, IMS, and VSAM. Additionally, z/OS data set encryption gives clients the ability to eliminate storage administrators from the compliance scope.

Database encryption provides selective encryption and granular key management control of sensitive data. Lastly, application encryption can be used to encrypt sensitive data when lower levels of encryption are not available or suitable.

The Integrated Cryptographic Service Facility (ICSF) provides z/OS integrated software support for data encryption, and an OS software API to Cryptographic Hardware. The good news is that the hardware gets faster at what it does with each new processor model. There’s enhanced key management for key creation and distribution. This includes public and private keys, secure and clear keys, and master keys. The created keys are stored/accessed in the Cryptographic Key Data Set (CKDS) with a unique key label. The CKDS itself is secured using the Security Access Facility.

Other cryptographic hardware features include:

                CP Assist for Cryptographic Function (CPACF), which is a feature on the processor unit. CPACF adds instructions to the CPU, speeding up CPU processing for encryption.

                The Crypto Express (CEX) feature complements IBM Z cryptographic features. CEX speeds up encryption processing. With CEX, encryption requests go off to a separate card and come back, so while CEX uses more “wall clock” time than CPACF, the CPU time is a lot faster. CEX has a tamper-resistant design. If the tamper sensors are triggered, the box will self destruct, destroying critical keys and certificates, and rendering itself permanently inoperable.

Master keys are used to generate, encrypt and store user keys into the CKDS. They’re loaded into the CEX hardware, and not stored elsewhere. User keys (data encrypting keys) are generated through ICSF services, stored inside the CKDS, may be public or private, clear or secure, and are used by the IBM InfoSphere GDEz Encryption Tool along with the encryption algorithm to convert user data to ciphertext for database encryption.

A clear key is exposed in the storage of a processor and can be viewed in a dump of storage. If this is correctly interpreted, it can expose data. It’s used in software-based cryptography, so CPACF and the CEX hardware is not required. A secure key is only ever exposed in bounds of a secure processor and can never be seen in storage or a dump. It’s held encrypted under the master key. APIs are available via ICSF, and a secure key can be used from Java on z/OS.

Application encryption requires changes to applications to implement and maintain. It’s highly granular and protects data right up to the point where it will be used. The applications must be responsible for key management, and it’s a suitable technique for selective encryption of hyper-sensitive data.

Database encryption encrypts sensitive data at the Db2 row and column levels and IMS segment level. It’s transparent to applications. It requires Separation of Duties (SOD) and granular access control. It protects data in use within memory buffers, and clear text data cannot be accessed outside DBMS access methods. The sensitive data in logs, image copy data sets and DASD volume backups are also encrypted. It utilizes IBM Z integrated cryptographic hardware.

How Pervasive Encryption Works With CICS and IMS

Capabilities such as z/OS data set encryption and z/OS Coupling Facility encryption allow users to protect CICS data in a way that’s transparent to applications and databases. Pervasive encryption can be used with any in-service release of CICS. Users can encrypt any CICS data with just a few one-time set up steps. Typically, there’s very low CPU overhead on CICS transactions after enabling data set encryption and Coupling Facility encryption.

With IMS, Db2 and VSAM, data set encryption is enabled by policy, transparent to applications, tied to access control and uses protected encryption keys. It can be used to broadly encrypt data at rest. It can encrypt in bulk, for low overhead, and utilizes the integrated cryptographic hardware. With data set encryption, no application changes are required. A data set is defined as “encrypted” when a key label is supplied either on or prior to allocation of a new sequential or VSAM extended format data set.

Hardware encryption provides protection against intrusion, tamper or removal of physical infrastructure. It protects at the DASD subsystem level. It provides all-or-nothing encryption, but only data at rest is encrypted. A single encryption key is used for everything. There’s no application overhead and zero host CPU cost. It prevents exposures on disk removal, box removal and file removal.

With cyberattacks so prevalent and fines for non-compliance with regulations getting to be so expensive, it makes sense for organizations to take a very close look at the pervasive encryption features available on the most recent IBM mainframes—and that includes businesses that might not currently be using a mainframe.