|
Home > |
|---|
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.
Note: This feature is not currently supported for use with IPv6 networks.
NTLS and STC connections are best suited for different practical applications. Here are some examples:
•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.
•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 HSM card within the appliance
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.
Note: STC is incompatible with the PE1746 component of the Luna 6.x HSM card. If PE1746Enabled=1 under [Misc] in chrystoki.ini/chrystoki.conf, it will be disabled on a per-session basis when partitions are configured for STC.
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, modify, or replay the messages sent over an STC link.
•Bi-directional endpoint authentication. Each endpoint (HSM 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.
STC connections are established in two distinct phases:
1. Secure tunnel creation. To ensure client integrity, STC performs bi-directional HSM/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.
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 HSM client workstation (SafeNet Client to HSM). In addition, all STC links that use a network connection also use the same network protection as NTLS links, that is, they are wrapped using SSL.
On a SafeNet 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 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
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.
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
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.
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 is intentionally portable. That is, it can be moved or copied to another host and used – so any client that possesses this identity pair is considered the authentic client. Allowing this enables an elastic client model – an important capability 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.
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.
Before STC can establish a tunnel, it requires that trust has been established between the client and the partition. This trust relationship 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 done.
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 PSO 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.
9.Once bi-directional STC 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.
In the event all registered clients for a legacy partition are lost, there is no way the partition user or security officer can connect to the partition. As a recovery method, the HSM security officer has the ability to delete all registered clients to the partition. When deleted, the partition’s objects remain intact, but only restricted clients are allowed to connect. As such, the partition security officer needs to repeat the steps above to register the authorized clients.
Note: This procedure is not available 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.
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 perform the following tasks:
1.Exchange credentials.
2.Establish a unique session ID for the tunnel.
3.Create unique message authentication and message encryption keys for the session.
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.
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.
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 the following security features. 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.
You can configure the STC links to use a symmetric encryption cipher algorithm (AES 128, AES 192, or AES 256) to encrypt the data traversing the link. You can also disable encryption for STC links to a partition, if desired.
You can configure the STC links to use an HMAC message digest algorithm (SHA 256 or SHA 512) to verify each message traversing the link. Once STC enabled, message integrity verification is automatic and cannot be disabled.
You can configure the size of the packet replay window for for STC links to a partition. This value specifies the number of packets in the window of sequenced packets that are tracked to provide anti-replay protection.