Pervasive encryption is a consumable approach to enable extensive encryption of data in-flight and at-rest to substantially simplify encryption and reduce costs associated with protecting data and achieving compliance mandates.
Pervasive encryption is a system-wide solution. It reduces cost and remove vulnerability of ordinary encryption. Actual encryption is performed by dedicated cryptographic hardware (CPACF & Crypto Express discussed in this article later). Thus, pervasive encryption requires significantly less effort for secured encryption, and it is more cost effective than traditional software encryption solutions.
With pervasive encryption, data is always secure. Applications and even operating system cannot access key which encrypt data. Key is generating and encrypted by hardware. LPAR and applications cannot view the key in clear text form.
The IBM z14™ (z14) platform (or above) provides pervasive encryption capabilities designed to enable customer to protect data efficiently, and without requiring application changes. z14 (or above) provide following hardware support for Pervasive Encryption.
- CPACF - The Central Processor Assist for Cryptographic Function (CPACF) delivers cryptographic support for Advanced Encryption Standard (AES), Triple DES (TDES) and Data Encryption Standard (DES) encryption/decryption, as well as Secure Hash Algorithm (SHA). z14 has one CPACF for every Central Processor (CP), therefore, CPACF encryption throughput scales with the number of CPs in the system. The CPACF hardware can be accessed either via ICSF callable services or by Message Security Assist instructions provided by the system architecture.
- Crypto Express6S - The Crypto Express6S feature is designed to satisfy high-end server security requirements. The Crypto Express6S feature is configurable and can be defined for secure key encrypted transactions (CCA Coprocessor – the default, or Enterprise PKCS #11 Coprocessor) or clear key SSL acceleration (Accelerator). z/OS data set encryption require the Crypto Express feature to be configured as a CCA coprocessor. The Crypto Express6S feature has been designed to satisfy the security requirements of an enterprise server. For z14, the Crypto Express6S works with ICSF FMID HCR77C1 and the IBM Resource Access Control Facility (RACF®) in a z/OS operating environment to provide cryptographic services with the IBM Common Cryptographic Architecture (CCA) or the IBM Enterprise PKCS #11 (EP11) protocol.
The CPACF has both the cryptographic suite and performance characteristics that can enable bulk encryption of sensitive business data that makes it possible to fortify, intrinsically protecting business data using encryption technology. Working with the Crypto Express6S feature, the key materials used to create this fortified data perimeter are protected, using the IBM Z unique protected key CPACF in which the keys used in the encryption process are not visible to the applications and operating system in clear text form.
z/OS 2.3 (or above) provide support for Pervasive Encryption. Pervasive Encryption require that ICSF is installed and configured with a Cryptographic Key Data Set (CKDS) and AES master key loaded.
- ICSF - IBM® Integrated Cryptographic Service Facility (ICSF) callable services and programs help users generate, maintain, and manage keys. ICSF provides APIs by which applications request cryptographic services. Customers must also configure a CKDS data set to store keys. Data set encryption requires the use of AES master keys.
z/OS Capabilities for Pervasive Encryption
z/OS provides following capabilities for pervasive encryption
- z/OS data set encryption
- z/OS Coupling Facility encryption
- z/OS Readiness Technology (zERT)
z/OS data set encryption
z/OS® data set encryption enables encryption through the Data Facility Storage Management Subsystem (DFSMS) access methods. Customer can use z/OS data set encryption to encrypt the following types of data sets:
- Sequential extended format data sets, accessed through BSAM and QSAM
- VSAM extended format data sets (KSDS, ESDS, RRDS, VRRDS, LDS), accessed through base VSAM and VSAM RLS
Encrypted data sets must be SMS-managed extended format. They can be compressed format, also.
If you plan to encrypt SMF data sets or other data sets used during z/OS® initialization, you must ensure that ICSF is started early in the IPL process to avoid delays in z/OS initialization and termination. As such, it is highly recommended that the command S CSF,SUB=MSTR is placed early in the COMMNDxx member to ensure minimum delay in z/OS initialization. Specifying SUB=MSTR is necessary to allow ICSF to start before JES.
Furthermore, during z/OS system shutdown, ICSF must be one of the last features to stop so that dependent functions are not impacted. It is highly recommended that you shut down ICSF after terminating the JES address space and after initiating SMF halt processing. Note when ICSF is stopped after SMF is halted, that there might not be an SMF record cut for the termination of ICSF. (The ability to start ICSF with SUB=MSTR is available on all supported releases of ICSF.)
z/OS Coupling Facility Encryption
On systems at the z/OS® V2R3 level and above, list and cache structure entry and entry adjunct data can be encrypted while the data is being transferred to and from the coupling facility and while the data resides in the coupling facility structure. List and cache structure services use secure cryptographic key tokens obtained from the z/OS Integrated Cryptographic Service Facility (ICSF) software element to encrypt and decrypt user provided structure data. Encryption of structure data can be controlled on a structure-by-structure basis.
z/OS Encryption Readiness Technology
z/OS® Encryption Readiness Technology (zERT) is provided by the z/OS V2R3 Communications Server. With zERT, the TCP/IP stack acts as a focal point in collecting and reporting the cryptographic security attributes of IPv4 and IPv6 application traffic that is protected using the TLS/SSL, SSH and IPSec cryptographic network security protocols. The collected connection level data is written to SMF in new SMF 119 subtype 11 records for analysis. Additionally, a new real-time network management interface (NMI) service is provided for network management applications to retrieve zERT SMF records as they are generated.
Using zERT, you have a single source of information to determine which traffic is cryptographically protected by TLS/SSL, IPSec and SSH, and which is not. For the traffic with recognized cryptographic protection, you can determine which cryptographic protocol is used, which cryptographic algorithms are used, the length of the cryptographic keys, and other important attributes of the cryptographic protection. This information is valuable for determining regulatory compliance and for identifying connections that might need stronger cryptographic protection.
Article refer contents from following sources: