|
Home > |
|---|
An HSM with Host Trust Link (HTL) enabled will not allow an NTLS connection with a client instance until the Host Trust Link establishes that the client requesting NTLS is the correct instance of that client.
Note: This feature is not currently supported for use with IPv6 networks.
HTL is designed to protect a client instance running on a virtual machine (VM). An unprotected client running on a VM is vulnerable to an internal attacker who could make a complete copy of the running VM, in an attempt to impersonate the original client. The following layered protections mitigate this risk when the HTL link is active:
•Binding to IP
NTL binds the original VM to one IP address. If a clone of this VM is made with a different IP address, it will be unable to use the HSM. If a clone is made and assigned the same IP address, either the original VM would have to be killed (a noticeable event) or there would be network collisions (also detectable).
•TLS encrypted communications
All HTL counter values and synchronization packets are sent over a TLS link encrypted with a dynamically generated secret. This secret is in turn derived from a private key and certificate that are generated specifically for that VM instance during the HTL setup sequence. This arrangement makes it extremely unlikely that an attacker could use a cloned VM to “take over” an existing HTL connection as they would confront the hijacking protections of the TLS protocol.
•One-time tokens
The binding protocol requires a One Time Token (OTT) from the SafeNet HSM appliance, generated specifically for that client instance. This prevents an attacker, cloning a VM at rest, from using the cloned image to connect to the SafeNet HSM.
•Random data used in generating One Time Tokens
The data used to generate one-time-tokens is derived from the HSM’s hardware Random Number Generator (RNG complying with NIST SP 800-90), assuring maximum randomness, and therefore highest quality input to the process.
•One-time-token auto-refresh
The HTL maintains a constantly changing synchronization code with the HSM server, based on a random initial counter value and step interval assigned by the HSM, which allows the authorized instance to re-establish its HTL after brief periods. The length of this period is configurable by the HSM administrator and it defaults to 2 minutes. Administrators can lengthen the time for improved reliability if the network links are unreliable, or shorten the time to increase the overall security of the HTL.
When the HTL mode is active, then any unauthorized copy of the VM will be rejected by the HSM (until it receives a valid One Time Token). For such an attack to succeed, the counter would need to be re-synchronized to match the original VM by manipulating its value in RAM. This attack might be possible, but the use of a random initial counter value, a random step interval, and the ongoing synchronization, presents a significant barrier.
If a client requires VM binding, and an existing HTL link for that client goes down, the HSM server kills all existing NTLS connections from that client. This action occurs immediately, and is independent of the grace period (if any).
A client user, using a supplied GUI tool, can check the status of the HTL link for every configured, registered appliance.