Ssl/Tls, Ecc, And Rsa - Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

Chapter 3. Supported Standards and Protocols
• The default internal PKCS #11 module, which comes with two tokens:
• The internal crypto services token, which performs all cryptographic operations such as
encryption, decryption, and hashing.
• The internal key storage token ("Certificate DB token"), which handles all communication with the
certificate and key database files that store certificates and keys.
• The FIPS 140-1 module. This module complies with the FIPS 140-1 government standard for
cryptographic module implementations. The FIPS 140-1 module includes a single, built-in FIPS
140-1 certificate database token, which handles both cryptographic operations and communication
with the certificate and key database files.
Any PKCS #11 module can be used with the Certificate System. To use an external hardware token
with a subsystem, load its PKCS #11 module before the subsystem is configured, and the new token is
available to the subsystem.
Available PKCS #11 modules are tracked in the secmod.db database for the subsystem. This file can
be modified using the modutil tool, and it should be modified when there are changes to the system
like installing hardware accelerators to use for signing operations. For more information on modutil,
see http://www.mozilla.org/projects/security/pki/nss/tools/.
PKCS #11 hardware devices also provide key backup and recovery features for the information stored
on the hardware token. Refer to the PKCS #11 vendor documentation for information on retrieving
keys from the tokens.

3.2. SSL/TLS, ECC, and RSA

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are universally accepted
standards for authenticated and encrypted communication between clients and servers. Both client
and server authentication occur over SSL/TLS.
SSL/TLS uses a combination of public key and symmetric-key encryption. Symmetric-key encryption
is much faster than public-key encryption, but public-key encryption provides better authentication
techniques. An SSL/TLS session always begins with an exchange of messages called the SSL
handshake, initial communication between the server and client. The handshake allows the server
to authenticate itself to the client using public-key techniques, then allows the client and the server
to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper
detection during the session that follows.
Both of these protocols support using a variety of different cryptographic algorithms, or ciphers, for
operations such as authenticating the server and client, transmitting certificates, and establishing
session keys. Clients and servers may support different cipher suites, or sets of ciphers. Among other
functions, the SSL handshake determines how the server and client negotiate which cipher suite they
will use to authenticate each other, to transmit certificates, and to establish session keys.
Key-exchange algorithms like RSA and Elliptic Curve Cryptography (ECC) govern the way the server
and client determine the symmetric keys to use during an SSL session. The most common SSL cipher
suites use RSA key exchange, while TLS supports ECC cipher suites as well as RSA. The Certificate
1
System supports both RSA and ECC public-key cryptographic systems.
Only RSA is supported natively. External PKCS#11 modules with ECC support must be loaded for subsystems to use ECC.
42