Certificates, TLS and encryption

Data on the mainframe is protected in transit with TLS and at rest with encryption. On z/OS, certificates live in keyrings managed by the ESM, AT-TLS adds TLS to applications through policy, and pervasive encryption uses ICSF and hardware to encrypt datasets.

Certificates and keyrings

A digital certificate binds an identity (a server name or a user) to a public key, signed by a certificate authority (CA). On z/OS, certificates and their private keys are usually stored in the ESM database and grouped into keyrings. A server task such as a web listener or MQ channel is configured with the name of a keyring, and the ring holds its own certificate plus the CA certificates it trusts.

In RACF, certificates are managed with the RACDCERT command. ACF2 and Top Secret have their own equivalent commands. Private keys can also be stored in hardware through ICSF for extra protection.

Common RACDCERT tasks (concept level)What it means

RACDCERT ID(user) GENCERT ...

Generate a key pair and certificate

RACDCERT ID(user) GENREQ ...

Create a certificate request to send to a CA

RACDCERT ID(user) ADDRING(ring)

Create a keyring owned by that user

RACDCERT ID(user) CONNECT(...)

Attach a certificate to a keyring

RACDCERT ID(user) LISTRING(ring)

Show what a keyring contains

TLS and AT-TLS

TLS encrypts a network connection and lets each side check the other's certificate. Some z/OS applications implement TLS themselves using System SSL. AT-TLS (Application Transparent TLS) moves that work into the TCP/IP stack: the application sends and receives plain data, and TCP/IP applies TLS according to a policy.

AT-TLS components

Policy filesrules and actions

Policy AgentPAGENT started task

TCP/IP stackTTLS enabled

Encrypted connectionkeyring from ESM

The Policy Agent reads policy files and installs them in the TCP/IP stack, which must have TTLS enabled in its profile. A rule matches connections, for example by local port, and points to actions that say whether TLS is on, which role the stack plays and which keyring to use. Many sites build policies with the network configuration assistant in z/OSMF rather than by hand.

Fragment of an AT-TLS policy (illustrative)

TTLSRule PayApiServer
{
  LocalPortRange       8443
  Direction            Inbound
  TTLSGroupActionRef   GrpOn
  TTLSEnvironmentActionRef EnvSrv
}
TTLSEnvironmentAction EnvSrv
{
  HandshakeRole        Server
  TTLSKeyringParms { Keyring PAYRING }
}

Supported TLS versions and cipher suites depend on your z/OS level and site standards. Older protocol versions are normally disabled by policy.

Encryption at rest: pervasive encryption

Pervasive encryption is IBM's approach to encrypting large amounts of data on IBM Z with little application change. The core pieces:

CPACF: cryptographic instructions on every processor core make bulk encryption fast.
Crypto Express cards: tamper-resistant hardware security modules that protect master keys.
ICSF: the z/OS software that manages keys (for example in the CKDS key store) and offers crypto services to programs.
z/OS data set encryption: an extended-format dataset (and, on newer z/OS levels, a basic or large format sequential dataset) is assigned a key label (through the dataset profile, SMS data class or JCL), and DFSMS encrypts it as it is written.

The policy point is that access to encrypted data needs two permissions: access to the dataset and access to the key label (in RACF, the CSFKEYS class). A storage administrator can be allowed to move or back up a dataset without being allowed to read its contents. Coupling facility structures and network traffic can also be encrypted, and tools can report which connections are protected.

Certificates and keyrings

TLS and AT-TLS

Encryption at rest: pervasive encryption

Common mistakes

What you will see at work

Key terms