HP Secure Key Manager - Manual (Page 180)

Description Component
Select the IP addresses on which the FIPS Status Server is enabled on the SKM. Local IP
Select the port on which the server status report is available. Default is 9081. Local Port
SSL overview
The SKM is designed to be able to establish Secure Sockets Layer (SSL) and Transport Layer Security
(TLS) connections with all applications and databases that make requests to the KMS Server. SSL and
TLS are the most widely deployed security protocols in network security. The following section provides
a brief overview of the SSL protocol so that you might better understand how to configure the SKM.
SSL is used to establish secure connections between two entities, such as a client application and a
KMS Server. In addition to securing connections, SSL is commonly used to authenticate a server to a
client and vice versa. The SSL protocol is composed of two phases: (1) establishing a secure connection
using the SSL handshake protocol, and (2) exchanging data over the secure connection.
SSL Handshake
The following steps describe a typical SSL handshake:
1. The protocol is initiated by the requesting application using a client hello message. This message
includes a list of all the ciphers supported by the client application. The application also sends
a session ID that might refer to previously established sessions.
2. The SKM responds with a server hello message, which includes the SKM's certificate and the
cipher chosen by the SKM. Once the session is established, it is secured using the chosen cipher.
The message also contains a session ID.
3. The application and the SKM then engage in a key exchange protocol. The result is a session
key that is then used for encrypting the entire session.
Once the SSL handshake is completed, the two sides begin exchanging application data, such
as cryptographic operations, data migration operations, and so on. All data is encrypted using
the negotiated session key.
SSL Session Resume
Because the SSL key exchange protocol is based on public key cryptography, it consumes significant
computing resources. To minimize the number of SSL handshakes, SSL provides a shortcut to a full
key exchange. Consider an application that has previously established a secure session with the SKM.
Both the application and the SKM already share a session–key. When the application reconnects to
the KMS Server, there is no need to renegotiate a session key. During the reconnection process the
two sides execute the SSL resume protocol, which bypasses the key exchange part of the SSL
handshake. The resumed session is encrypted using the previously negotiated session–key. Establishing
a secure connection using SSL resume is much faster than a full SSL handshake.
In this scenario, the client application indicates that it is willing to perform an SSL resume (rather than
a full handshake) by sending a previously negotiated session–id in the CLIENT–HELLO message. The
SKM checks that it has the session key for the given session–id. If so, it acknowledges that it is willing
to resume the session by using the same session–id in the SERVER–HELLO message. Otherwise, the
SKM responds with a new session–id.
Using the Management Console 180