Encryption algorithms

After authentication occurs, the client and server must agree on a symmetric encryption method and generate a single encryption key to use for data encryption. The chosen key is exchanged by using the PKI method of encryption. After the symmetric encryption algorithm (such as AES) and a single encryption key are chosen, all data exchanges use this algorithm and key instead of the PKI method of encryption.

In an SSL-encrypted session, all data is encrypted with the symmetric encryption algorithm immediately before it is sent to the client. Data from the client is decrypted immediately after it is received. The encryption algorithm that is used for the connection depends on a combination of the following factors:

  • The encryption algorithm list that the SSL subsystem supports
  • The list that the server wants to use
  • The encryption algorithms that the client requests

During the SSL handshake, the client sends a list of encryption algorithms it is able to use. The server submits its list and the SSL subsystem picks an algorithm that all parties support, giving preference to the order that the server specifies. If the server does not support any of the encryption algorithms that the client requests, the connection is closed. Start of changeAT-TLS and a small number of z/OS® Communications Server applications use the TLS/SSL support that is provided by the System SSL component of the z/OS Cryptographic Services element of z/OS. The strength of cryptographic algorithms available through System SSL depends on the level of System SSL that is installed. End of change

Start of changeThe System SSL base FMID provides cryptographic support up to 56-bit in strength. In order to use cryptographic support greater than 56-bit (for example, Triple DES, AES, ChaCha-Poly1305, etc.), either the System SSL Security Level 3 FMID must be ordered and installed or the CP Assist for Cryptographic Functions (CPACF) DES/TDES Enablement Feature 3863 must be installed. For more information about installing the Security Level 3 FMID, see z/OS Program Directory.End of change The encryption algorithm list can be customized for the servers and client to a subset of the System SSL list. For specific server and client statements that are used to create the encryption list, see the security information for the appropriate server or client.

Encryption is provided by either hardware, if available, or software algorithms within System SSL or Integrated Cryptographic Services Facility (ICSF). There is no TCP profile definition to control whether the cryptographic hardware is used for secure connections. For information about cryptographic hardware usage within System SSL, see z/OS Cryptographic Services System SSL Programming. To use FIPS 140 mode, ICSF must be started and available to System SSL.

If hardware encryption is to be used, be sure that the RACF® user ID associated with the server has read access to the RACF CSFSERV class resources. If ICSF is available but the server has not been given access to these resources, the SSL initialization may fail. The reason code is likely to be 4 (bad password) because System SSL will attempt to use the hardware encryption during processing of the key ring.