STC Overview
STC protects your HSM/client communications using endpoint and message authentication, verification, and encryption. With STC, HSM/client message integrity is ensured, even when those messages are sent over public or otherwise unsecured networks. You can use STC links to confidently deploy HSM services in cloud environments, or in situations where message integrity is paramount.
STC is a tunnel (client to partition - terminates inside the HSM) within a tunnel (STC daemon, network portion, client to appliance).
When to Use: Comparing NTLS and STC
NTLS and STC connections are best suited for different practical applications. Here are some examples:
NTLS
>Ideally suited for high-performance applications and environments, executing many cryptographic operations per second.
>Best used in traditional data center environments, where the client can be identified by its IP address or hostname.
>If you plan to use Functionality Modules (FMs) on your HSM, you cannot use STC client connections. Use NTLS connections instead (see FM Deployment Constraints).
STC
>Suited for applications with moderate performance requirements
>Preferred where applications are running on physical servers and HSM client credentials are stored on a physical token
>Suited for higher-assurance applications requiring session protection beyond TLS; STC’s message integrity and optional additional layer of encryption offers additional protection of client-to-HSM communications
>Best for virtual and cloud environments where virtual machines are frequently cloned, launched, and stopped -- such as when virtual machine auto-scaling is implemented to meet SLAs
>Preferred in "HSM as a Service" environments where multiple customers, departments, or groups all access partitions on a common HSM and want communication to be terminated on the SafeNet Luna HSM card within the appliance
Performance consideration while using STC
STC introduces additional overhead to the communication channel. Depending on the application use case and cryptographic algorithms employed, this could have an impact on application performance.
Security features
STC offers the following security features to ensure the privacy and integrity of your HSM/client communications:
>Symmetric encryption. This ensures that only the STC end-points can read data transmitted over an STC link.
>Message authentication. Message authentication codes are used to ensure the integrity of the communicated data, to prevent attacks that attempt to add, delete, or modify the messages sent over an STC link.
>Mutual partition/client authentication. Each endpoint (partition or client) is assigned a unique identity, which is stored as a hardware or software token. This ensures that only authorized entities can establish an STC connection, and eliminates the risk of a man-in-the-middle attack. See Client and Partition Identities.
Secure tunneling and messaging
STC connections are established in two distinct phases:
1.Secure tunnel creation. To ensure client integrity, STC performs mutual partition/client authentication, and creates unique session keys for each STC connection, as described in Secure Tunnel Creation.
2.Secure message transport. To ensure message integrity, STC uses symmetric data encryption and message integrity verification, ensuring that any attempt to alter, insert, or drop messages is detected by both end-points, resulting in immediate termination of the connection, as described in Secure Message Transport.
All messages protected outside the HSM
When STC is fully enabled on an HSM, all sensitive communications with the HSM are protected all the way into the HSM. That is, any messages exchanged between a client application and the HSM use STC encryption, authentication, and verification from the client interface to the HSM interface, regardless of whether those links traverse a network, or are internal to an HSM appliance (LunaSH to HSM) or SafeNet Luna HSM client workstation (SafeNet Luna Client to HSM). All STC links that use a network connection also have the same network protection as NTLS links, that is, they are wrapped using SSL.
On a SafeNet Luna Network HSM appliance, there are two separate STC link types, which are configured separately:
> Between the client and a partition. These links are configured as described in Creating an STC Link Between a Client and a Partition in the Configuration Guide. Each client-partition link is configured separately.
>Between the local services and applications running on the appliance (such as LunaSH, NTLS, and the STC service) and the HSM SO partition. This link is called the STC admin channel, and is configured as described in Establishing and Configuring the STC Admin Channel on a SafeNet Luna Network HSM Appliance.
The STC admin channel is local to the appliance, and is used to transmit data between the local services and applications running on the appliance (such as LunaSH, NTLS, and the STC service) and the HSM SO partition.
Configurable options
The security features offered by STC are configurable, allowing you to specify the level of security you require, and achieve the correct balance between security and performance. Client/partition STC link parameters are configured using LunaCM. LunaSH/partition STC link parameters are configured using LunaSH.
Client and Partition Identities
The identity of a client or partition at an STC endpoint is defined by a 2048-bit RSA asymmetric public/private key pair, unique to each endpoint. Before you can establish an STC link, you must exchange public keys between the client and partition to establish trust.
Figure 1: Creating an STC Link Between a Client and a Partition
Partition Identities
The partition private key is always kept in the HSM and is strongly associated with its partition. Only the partition security officer can retrieve the partition’s public key for delivery to a client. Upon receipt, the client administrator can use the public key hash to confirm its authenticity, before registering it. You can register multiple partition public keys to a client.
Client Identities
By default, the client’s identity pair is stored in a software token on the client’s file system, protected by the operating system’s access control systems. When using a software token, the client’s private key can be moved or copied to another host and used – so any client that possesses this identity pair is considered the authentic client. This enables an elastic client model for many applications.
If you require stronger client authentication, you can choose to use a SafeNet eToken 7300 hardware token to protect the client’s private key. When using hard tokens, the client’s private key is marked as non-extractable, so only a host with the hard token inserted can successfully authenticate to the HSM partition. The SafeNet eToken 7300 is a FIPS 140-2 Level 3 device.
NOTE After establishing an STC link, the hardware token can be removed from the host computer for safe storage. If the STC link goes down, the hardware token is required to re-establish the link.
Secure Tunnel Creation
Each STC connection is established between a client application and a specific partition on the HSM. As such, each application and partition pair goes through STC tunnel establishment individually. Before STC can create secure tunnels, trust must be established between the client and the partition through the manual exchange of public keys. Once trust has been established, STC links between the client applications and the partition are created.
Establishing Trust Between the Client and the Partition
The trust relationship between the client and the partition is built as follows:
1.When you create a partition, the STC partition identity asymmetric key pair is generated automatically, and stored in the partition.
2.The partition SO extracts the partition’s STC public key and provides it (out of band) to the client administrator.
3.The client administrator enables STC on the client machine, if not already enabled.
4.The client administrator registers the partition identity provided in step 2 to the client token (software token or hardware token, as configured). The client administrator can verify the hash of the partition public key before registering it to the client, if desired.
5.The client administrator creates the STC client identity asymmetric key pair, on the client token. This will also automatically export the generated STC client public key to a file.
• If you are the partition SO, connecting to your un-initialized partition, skip to step 8. Your STC client registration will occur automatically when you initialize the partition.
•For all others, proceed to step 6.
6.The client administrator takes the client identity public key that was exported automatically during step 5, and provides it (out of band) to the partition SO.
7.The partition SO registers the client’s STC identity public key to the partition.
8.The client can now connect to the partition.
NOTE For the partition SO, if this the first time connecting to your uninitialized partition, your client identity will be automatically registered to the partition when you issue the LunaCM partition initialize command.
Once mutual partition/client public key registration is complete, registered and authorized client applications can establish fully authenticated and confidential STC tunnels with the partition.
Once this sequence is completed the partition will only accept authenticated STC connections from a registered client. You can register additional partitions with this client machine by repeating this process. You can register additional clients to a partition, but any additional client identities need to be registered by the partition SO from a pre-registered client machine.
Recovering lost clients
It is not possible to recover lost clients for PSO partitions as the HSM security officer has no access to the partition once it has been initialized. Therefore, if all registered client tokens to a PSO partition are lost, the only recourse is to have the HSM security officer delete and recreate the partition. The partition objects are lost in this case.
Establishing a Secure Tunnel Between a Client Application and a Partition
Once public keys have been exchanged between a client and a partition, STC is able to establish a secure tunnel between a client application and the partition. To establish a tunnel, the client and partition use secret handshaking to exchange credentials, establish a unique session ID for the tunnel, and create unique message authentication and message encryption keys for the session.
Session Re-Negotiation
Session keys for tunnel are periodically renegotiated, as specified by the STC rekey threshold set for a partition. The rekey threshold specifies the number of API calls, or messages, that can be transmitted over an STC link to the partition before the session keys are renegotiated. You can adjust this value based on your application use cases and security requirements. See Configuring the Network and Security Settings for an STC Link for more information.
Abnormal Termination
When a client shuts down a connection under normal conditions, it sends a secured message informing the HSM that the connection can be terminated. If a client terminates abnormally, or the network link is lost, the STC Daemon (STCD) detects the abnormal termination, and sends a message to the HSM informing it that the connection has ended, and the connection is closed. If the STCD sends an incorrect connection termination message, the client transparently re-establishes a new STC tunnel.
Secure Message Transport
Once a secure tunnel is established, any messages sent over the STC link are encrypted and authenticated using the unique session keys created when the tunnel is established. In addition, as with NTLS, all STC links use the TLS protocol to secure the link when it traverses a network.
Messages traversing an STC link are protected using Symmetric Encryption and Message Integrity Verification. These features are configurable for each partition and are used for each STC link to that partition. See Configuring the Network and Security Settings for an STC Link for more information.
