The coprocessor design protects cryptographic keys and sensitive custom applications. The software running in the coprocessor can be customized to
meet special requirements.
A CEX2C can speed up an SSL connection as well, but it isn’t optimized for that purpose. Using CEX2A allows much higher SSL handshake rates.
Using Cryptographic Hardware
The SSL communication protocol was designed to provide secure communication over an open, insecure network. The connection between a client and server is established by executing a so-called SSL handshake process. During an SSL handshake, the keys for the symmetric cipher are exchanged and the type of symmetric cipher for the data encryption is negotiated. An asymmetric cipher, also known as a public key cipher, called RSA, is used for that purpose, which is quite CPU-intensive. However, SSL tries to use it as little as possible. SSL usually applies public key encryption only to agree on an encryption key for a symmetric cipher.
The CEX2A provides hardware support for the cryptographic functions SSL uses in the handshake process. By offloading these cipher calculations from the CP or Integrated Facility for Linux (IFL) to external cryptographic hardware, the overall SSL handshake rate can dramatically increase. As mentioned, the data exchanged via the SSL secured connection is encrypted with a symmetric cipher (e.g., TDES or AES-128).
Symmetric ciphers are used for encrypting larger data portions because they’re significantly faster than asymmetric ciphers. By choosing a symmetric cipher supported by the System z Central Processor Assist for Cryptographic Function (CPACF) of a certain System z machine, the overall SSL performance can be increased, too. There are several symmetric ciphers supported for that purpose. Usually, they differ in the number of bits used for the key length. For example, AES-128 uses 128 bits for the key length and AES-256 uses 256 bits. The more bits used for the key length, the more secure the symmetric cipher. A longer key length usually implies less cipher throughput performance and higher CPU costs—especially when the cipher must be calculated in software and CPACF acceleration can’t be used.
By offloading the symmetric cipher calculations from the CP to CPACF, you can reduce the CPU costs and gain higher SSL traffic throughput rates. Moreover, CPACF supports different flavors of secure hash functions, which the SSL protocol uses, too (see Figure 1).
The Linux on System z SSL Environment