|
Home > |
|---|
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 application server (a computer in a server room, acting as a client to the HSM, and acting as a server to your users), the HSM server (in that same server room, or another, providing secure cryptographic services and/or acceleration for your client-server transactions), 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:
•flexible
•portable
•not tied to a specific hardware platform.
Virtual Machines are being deployed in:
•Private Cloud – an enterprise creates its own virtual-machine environment to serve the enterprise’s constituent departments or business units; the private cloud remains invisible and inaccessible to outsiders
•Hybrid Cloud – an enterprise creates its own virtual-machine environment that it makes available for internal use and also provides as a service to its external customers
•Public Cloud – an enterprise creates a virtual-machine environment that it makes available as its primary service to businesses and individuals
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 traditional (steal the server) to virtual (steal the server Virtual Machine instance).
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:
•Ensure that a stored VM image, containing NTL credentials, cannot be cloned to establish an unauthorized NTLS connection to the Luna HSM server.
•Provide protection against cloning attacks after the VM binding has been established in a running VM.
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:
•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.
•The binding protocol requires a One Time Token (OTT) from the Luna 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 Luna HSM.
•Random data used in generating 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 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.