6.3.2 CPACF’s role in  acceleration and protection This section raises performance considerations for acceleration and protection. Acceleration: hardware encryption The CPACF provides on-chip acceleration for these operations by using instructions for SHA2  and SHA3 (hashing), AES, and new with IBM z15™ ECC (Elliptic Curve Cryptography)  including ECDSA. By performing these operations on a dedicated co-processor, on-chip,  these cryptographic algorithms run at the full clock speed of the processing chip and minimize  the latency that is caused by data transfer. This capability increases the performance of every  hashing and signing operation that the IBM Blockchain Platform employs. No intervention  from the user is required, besides enablement of the (no-charge) CPACF feature for AES.  Also, CPACF increases the performance of every connection that you make with TLS by  using the Advanced Encryption Standard (AES) instructions. CPACF also boosts  performance of the ECDA functions on the chip, in the case of IBM z15™. For examples of  how performance can increase with CPACF, look at the performance paper for CPACF on  z14, which are available in the following document:  [ https://www.ibm.com/downloads/cas/K4AR1NLQ  This performance paper includes detailed data for the z14 cryptographic operations that use  CPACF. The dat shows that speeds increase as amounts of data that is encrypted increase.  This is true because the loading of data is more efficient. The largest bottleneck becomes the  cryptographic operations themselves, which are being accelerated by the CPACF  coprocessor. Note:  The performance paper applies to IBM z14. Thus, it doesn’t describe ECDSA operations for  CPACF. In z15, these operations are available as part of CPACF in addition to the symmetric  encryption algorithms such as AES and hashing algorithms such as SHA2. In cryptography, your keys provide access to the data. Whoever has those keys has access.  This means that protecting keys is a top priority. LinuxONE and Linux on Z use true random  number generation (TRNG) to create keys. This approach improves security and throughput  of key generation. This capability is built into the Linux kernel and is transparently  implemented in crypto libraries to enhance the security of your system. Security: protecting keys from generation (true random) to use Beyond just generating a random key, it also implements measures to keep the key  protected. One of these measures is protected key. Protected key employs a wrapping key —  two per-LPAR keys (one for AES and one for DES/TDES) — that CPACF code creates and  stores in the protected area of the Hardware System Area (HSA). The wrapping key “wraps”  (encrypts) encryption keys to protect them. In this way, protected key keeps the encryption  key wrapped by its wrapping key in CPACF. When the key is outside of the addressable  program memory, it is in the clear only to Licensed Internal Code (LIC). This approach brings  these benefits: GLYPH<SM590000> Protects the key from running in the clear where it might be found by an attacker.  GLYPH<SM590000> Increases security for keys that are used for symmetric encryption for something like a  TLS connection.  For more information on what you can do with a protected key in Linux, see the following  explanation of the protected key driver for the Linux on Z operating system: https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.ljdd/ljd d_r_pkey.html 210  Implementation Guide for IBM Blockchain Platform for Multicloud