Cryptography Overview

MCP Cryptographic Services provides public-key (asymmetric) encryption as well as private-key (symmetric) encryption. Public-key encryption is usually used to encrypt session keys. Session keys, which are normally symmetric keys, are then used to encrypt and decrypt data.

In the public-key cryptography paradigm, each user has as public key and a private key. Encryption is performed with the public key, and decryption is performed with the private key. In symmetric key encryption, the same key is used to encrypt and decrypt.

In addition to encryption, MCP Cryptographic Services provides the ability to generate and verify digital signatures. Digital signatures, which can be attached to messages and documents, are also contained in digital certificates. Digital signatures serve to verify that the message, document, or certificate is really from the initiator, and not an impostor. Digital certificates are used in the process of authenticating a user to a server or service, or to authenticate a server or service to a user.

A certificate, which is a digital document, affirms that a public key belongs to an individual or entity. Certificates contain a public key and a name, and can also contain other information such as an expiration date, the certifying authority that issued the certificate, a serial number, and so on. The digital signature of the certificate issuer is the most important piece of information in the certificate.

Certificates are issued by a certifying authority, which is a trusted entity that vouches for the identity and public key of the user for whom the certificates were issued. The issuer authenticates the identity and the public key of an individual before issuing a certificate to that individual.

Similar to certifying authority (also called as Root-CA), there is another entity called intermediate certifying authority. The Root-CA signs the certificate of the intermediate certifying authority (also called intermediate-CA), thus trusting the intermediate-CA. The intermediate-CA can sign certificates of end systems on behalf of the Root-CA and in this way, a chain of trust is created resulting in chained certificates. ClearPath MCP systems can support certificate chains in both TLS 1.2 and 1.0 (disabled by default for TLS 1.0 and can be turned ON by the user using the ODT command NW TCPIP OPTION + TLS10CERTCHAIN when needed) versions.

In the ClearPath MCP environment, cryptographic keys have an associated MCP usercode. In order to access the key, the application must be running under that usercode. The usercode of *NULL is reserved for keys accessed from system services.

ClearPath MCP systems can process certificates that are signed using hash algorithms such as SHA-1, SHA-256, SHA-384, and SHA-512. Since SHA-1 signed certificates are deprecated, SHA1 option is disabled by default, which can cause the connection to fail. To use SHA-1 signed certificates, the system administrator must turn ON the SHA1 option using the ODT command NW TCPIP OPT + SHA1. Since the SHA-1 signed certificates are deprecated, the system administrator should turn OFF the SHA1 option after the connection has ended.

SHA-384 and SHA-512 signed certificates are only supported on those systems that have cryptographic services of version 1.33 or above.