Administration & Maintenance - HTL
The traditional model had an application server acting as a client engaging an HSM server so that together they could provide secured application and crypto services to end-users. The , the , and the end-user consumer of services were all individual computers in the physical possession and control of their various owners.
That model is going away, replaced by scenarios where application servers can be Virtual Machine instances, rather than individual specific computers.
Virtualization brings a number of benefits. Among those, a virtual client is:
Virtual Machines are being deployed in:
Both the traditional and virtual-machine environments rely on HSMs and HSM servers to secure data and transactions, and accelerate the cryptographic aspects of transactions, as well as to secure important keys and certificates.
The threat of a stolen Server has always been a security concern for Enterprises. Traditionally this form of attack was relatively difficult, as walking out of a Data Center with a server should be rather difficult. Historically, the Enterprise supplied their primary data product, such as database or application access, supported by back-room cryptographic services from SafeNet HSMs. The Enterprise provided physical security for their application/database servers and for their SafeNet HSMs and HSM Servers, while SafeNet products provided the link security via the Network Trust Link (NTL) service. This threat paradigm shifted significantly with the introduction of virtualized server instances.
The threat has now evolved from:
to
When the client employs the leverage of virtual hosting, that client could exist potentially anywhere in the world. The location could change at any time, unannounced. Importantly, multiple instances of a VM can be launched at any time, and control over the VM image is not fully under its nominal “owner’s” control. The fact that a Luna HSM server does not notice when a VM moves allows smooth operation of the client that is using the resources of that HSM. The HSM server neither knows, nor cares, that its assigned client VM is moving (or not); the crucial concern is that that HSM server knows it is always talking to the right VM. The possibility of an unauthorized VM clone arises out of the portability and reproducibility of VMs in general. This is the virtual-world equivalent of an unauthorized person walking out of a server room with an application server.
The challenge for an HSM serving virtual clients is to know that the HSM server is talking to the authorized instance of a virtual client, and no other. Virtual Machines in many cloud environments are 100% isolated from their physical environment, therefore no physical attribute (not a TPM, nor a CPU ID, nor a MAC address) can be used to lock down the VM. Similarly, cloud-service metadata, like any data, is easily copied and manipulated, and therefore is not suitable as a link-securing characteristic.
To protect against potential attacks, such as illustrated above, and to continue to offer “defense in depth”, SafeNet developed HTL, the Host Trust Link. HTL with its One-Time-Token solution is SafeNet’s built-in, HSM-based protection of HSM/Client registrations for cloud solutions.
With the VM decoupled from any specific piece of hardware or physical location, HTL uses a proprietary binding protocol to maintain the connection's association with a given VM regardless where that physical VM instantiation resides. The NTL service is still used, as before, but the new verification layer is added.
HTL supports two objectives:
The secret data used to protect the HTL link and ensure it cannot be spoofed or re-used is maintained only in RAM, which greatly increases the difficulty of an attack.
When deploying clients in VM/Cloud environments, it is possible to pre-configure each VM with NTLS credentials (assuming that a unique IP address can be supplied for each set) and to provision both the client and an HSM partition when convenient. A virtual client can then be launched and begin interacting with a Luna HSM server over an NTLS link, without specific setup steps required for that VM. A clone of that pre-configured client VM, in the wrong hands, could work as well.
The HSM with 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 VM instance of that client.
Once the VM is started and the HTL link is active, it might be possible for an internal attacker to make a complete copy of a running VM, in an attempt to impersonate the original client. The following layered protections mitigate potential concerns with respect to the provider security:
When the HTL mode is active, then ANY way an attacker manages to obtain an unauthorized copy of the VM it 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.
Why did we choose to create our own trust anchors to achieve the desired security when moving to a virtual environment, rather than relying on attributes available in the VM?
VMs are intended to be completely isolated from their physical environments. VM attributes are already difficult to find that
• are not static
• can reliably distinguish between VM instances, and
• are not easy to spoof.
The trend is toward greater isolation. HTL is a SafeNet-generated and controlled link-authentication protocol, independent of VM attributes. SafeNet OTT technology provides enhanced security for future clouds without giving up the benefits of the cloud.
HTL is introduced for the virtual environment because there is a pressing need to control a VM’s ability to connect. However, HTL can also help in the non-virtual world. Some customers are concerned that an attacker could grab the NTL private key file from a legitimate physical server, move it to a rogue server, and connect from there -- a physical world version of the malicious VM clone. HTL can address that concern.