Client-Partition Connections
To allow clients to perform cryptographic operations, you must first give them access to an application partition on the HSM. This section contains the following information about client-partition connections:
>Creating an NTLS Connection Using Self-Signed Certificates
>Creating an NTLS Connection Using Certificates Signed by a Trusted Certificate Authority
>Assigning or Revoking NTLS Client Access to a Partition
>Connecting an Initialized STC Partition to Multiple Clients
>Converting Initialized NTLS Partitions to STC
>Configuring STC Identities and Settings
>Restoring Broken NTLS or STC Connections
Comparing NTLS and STC
Client access to the Luna Network HSM is provided via two different types of channel:
| NTLS | STC |
|---|---|
|
>Does not encrypt data between network interface and HSM >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; not recommended for use with public networks. |
>Encrypts data between network interface and HSM >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 service-level agreements >Preferred in "HSM as a Service" environments where multiple customers, departments, or groups access partitions on a common HSM and want communication to be terminated on the Luna HSM card within the appliance >Suited for applications with moderate performance requirements |
Network Trust Link Service
A Network Trust Link is a secure, authenticated network connection between the Luna Network HSM appliance and a client computer. NTLS uses two-way digital certificate authentication and TLS data encryption to protect your sensitive data during all communications between HSM partitions on the appliance and its clients.
The NTLS architecture consists of:
>Network Trust Link Server (NTLS), which runs on the appliance and manages the NTLS connections to the appliance. NTLS uses port 1792 on the Luna Network HSM appliance.
>Network Trust Link Agent (NTLA), which runs on the client and manages NTLS connections to the client. The NTLA is included in the Luna HSM Client software.
The Luna Network HSM appliance can support up to 800 simultaneous NTLS connections.
The certificates that identify appliances and clients can be self-signed or signed by a trusted Certificate Authority (CA).
The certificate that identifies the appliance is always self-signed; the client certificate can be self-signed or signed by a trusted Certificate Authority (CA).
NTLS Authenticated by Self-Signed Certificates
The figure below shows how a secure NTLS connection is created using self-signed certificates exchanged between the client and the appliance.
Self-signed certificates are created on both the appliance and the client. These certificates are exchanged to register the appliance and client with each other. Once registered, the client can access any partitions assigned to it in LunaSH. NTLS encrypts data between the network interfaces of the appliance (eth0 above) and client, but not between the network interface and the HSM within the appliance.
There are two methods of assigning partitions to a client via a self-signed NTLS connection:
>A multi-step procedure, performed by the appliance administrator and a client administrator
>A single-step procedure that automates the manual process. It can be used when the client administrator has admin-level access to the appliance, or through a custom registration account (see Creating a One-Step NTLS Registration Role).
See Creating an NTLS Connection Using Self-Signed Certificates.
NTLS Authenticated by a Certificate Authority on the Client Side Only
The figure below shows how a secure NTLS connection is created using a self-signed appliance certificate and a client certificate signed by a trusted CA. This can be a commercial third-party CA or your organization's own signing station. This method requires Luna HSM Client 10.1.0 or newer.
A Certificate Signing Request (CSR) is created on the client; this is an unsigned certificate that must be signed by your trusted Certificate Authority. The signed certificate is installed on the client, and the CA certificate chain is added to the trust store on the appliance. Finally, the client certificate is registered on the appliance and the client is then able to access any partitions that are assigned to it.
NTLS Authenticated by a Certificate Authority
The figure below shows how a secure NTLS connection is created using client and server certificates signed by a trusted Certificate Authority (CA). This can be a commercial third-party CA or your organization's own signing station. This method requires minimum Luna HSM Client 10.1.0 and Luna Network HSM appliance software 7.7.0.
A Certificate Signing Request (CSR) is created on the appliance, the client, or both—this is an unsigned certificate that must be signed by your trusted Certificate Authority. Each signed certificate is installed on its respective appliance/client, and the CA certificate chain is added to both trust stores. Finally, the client certificate is registered on the appliance and the client is then able to access any partitions that are assigned to it.
See Creating an NTLS Connection Using Certificates Signed by a Trusted Certificate Authority.
Secure Trusted Channel
If you require a higher level of security for your network links than is offered by NTLS, such as in cloud environments, or in situations where message integrity is paramount, you can use Secure Trusted Channel (STC) to provide very secure client-partition links, even over unsecured networks. STC offers the following features to ensure the security and integrity of your client-partition communications:
>All data is transmitted using symmetric encryption; only the end-points can decrypt messages
>Message authentication codes prevent an attacker from intercepting and modifying any command or response
>Mutual authentication of the HSM and the end-point ensure that only authorized entities can establish an STC connection
The figure below shows how an STC connection is made between the client and an application partition.
See the following procedures:
>Connecting an Initialized STC Partition to Multiple Clients
>Converting Initialized NTLS Partitions to STC
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, unique session keys are created for each STC connection.
Session Re-Negotiation
Session keys for the 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 STC Identities and Settings 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 STC Identities and Settings for more information.
All messages protected outside the HSM
When STC is fully enabled on an HSM, all sensitive communications 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 the appliance (LunaSH to HSM) or Luna HSM Client workstation (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.
In addition to the STC connection between client and partition, you can also configure an STC connection between the HSM SO partition and the local services running on the appliance. This is referred to as the STC Admin channel.
See Using the STC Admin Channel.
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.
The partition's 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 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.
Performance Consideration
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.
