Securing Luna HSM Connections in
Virtual Environments
whitepaper
Background
The threat of a stolen computer has always been a security concern for Enterprises. In most IT
environments today that could apply to everything from personal smartphones/PDAs, laptops,
and personal computers up to large server platforms. This form of attack has, until recently,
necessitated the physical theft of the computer. For the smaller, more portable devices,
theft is relatively simple and the associated risk is quite high. For the server class platforms,
stealing a machine is quite difficult since they tend to be installed in fixed racks inside locked
data centers. Server theft, therefore, has typically not been seen as a high risk, and data
and services hosted on servers were perceived to be safe. With the rapid growth in the use of
virtualization technology, however, there is no longer a fixed link between data and services
and the physical “server” that hosts them. The threat has now evolved from:
• traditional = “steal the server” to
• virtual = “steal the server virtual machine”
Consequently, the sense of safety that many enterprises had, based on their physical security
measures, is being eroded since the data and services are no longer guaranteed to be
physically secure.
For network-attached HSMs, such as Luna SA, the increased risk associated with virtual
server theft means an increased risk of rogue servers connecting to the appliance using data
captured from the stolen virtual server. Some of the assumptions that were made during the
original design of the Luna SA’s network access control feature are no longer valid in a virtual
environment, and the overall security of the access control design had to be re-examined.
In the past, an HSM customer typically focused its attention on its core business logic and
data requirements, looking to SafeNet HSMs to provide key management and cryptographic
services as necessary. The customers owned the HSMs and application servers, and could
provide adequate physical security for their servers and their Luna SA network-attached
HSMs in their data centers, while the Luna SA HSMs provided network access control via the
Network Trust Link (NTL) service, protecting the organization’s keys within the confines of
the embedded HSM. NTL could rely on the fact that a limited (and fixed) number of servers
within a secure environment could be expected to connect to a Luna SA (that is, NTL could
Securing Luna HSM Connections in Virtual Environments Whitepaper
1
assume that the organization’s physical security would limit the opportunity for rogue servers
to attempt connections). This is no longer the case with the introduction of virtual servers
and cloud computing. A new protection mechanism is required to enable NTL to provide an
equivalent level of security in virtual server environments as it does when dealing with
“real” servers.
Luna HSM Server “real” clients
(Traditional/non-virtual) model
Application Servers on
real (non-virtual) hardware
Windows
Solaris
Linux
HP-UX
AIX
Luna HSM Server
(HSM inside)
NTL links secured
by SSL security,
certificate exchange
PKCS #11
SSL
Luna HSM Server admin
(SSH or serial connection)
ts
un
ss
w
or
d
co
or
ac
L
SS
d
ce
rt
JCA
an
ifi
ks
n
Li
ca
te
SSL
Li
n
te
ca
ks
ifi
rt
an
d
ce
ac
or
co
un
ts
d
or
w
ss
se
pa
cu
by
re
d
d
re
by
cu
pa
se
CAPI/CNG
Attacker
External points of attack are minimized if
security of premises and network are maintained.
Most likely attack is internal.
Securing Luna HSM Connections in Virtual Environments Whitepaper
2
Security Objectives
The security objectives that must be met by any solution intended to address the impact of
new “steal the Virtual machine instance” threat on the Luna SA include the following:
1.Identify the client virtual machine image (preferably the virtual machine instance, but that
may not always be practical or even possible).
2.Bind the identity of the client virtual machine image/instance to the TLS credentials
(private key and public key certificate) used to secure the network access link from the
client to the Luna SA.
3.Prevent unauthorized copying or movement of the virtual machine instance from one
physical computer platform to another.
4.Prevent the reuse and/or replay of any credentials/secrets used to meet the objectives in
numbers 1 through 3 above.
Discussion
Virtual machine technology itself brings a number of benefits to any computing environment.
Some of those benefits include:
• Flexibility – Virtual machines can be instantiated when required, and with the operating
system and application suite required for the task at the time.
• Portability – A virtual machine can be moved from one physical server to another; for
example, in the event the original host is showing signs of potential failure in the near
future.
• Scalability – Additional virtual machine instances can be spawned quickly to respond to
an actual or expected increase in processing workload.
When an organization takes advantage of virtual machine technology—such as in a
consolidated data center or private cloud, or when contracting with a public cloud service
provider—the organization’s client computers and the virtual machine host computers (that
might be replacing, for example, an organization’s database and ERP servers) could exist
anywhere in the world. Importantly, multiple instances of a VM can be launched at any time
(for example, in response to increased workload), and control over the location of the VM
image does not necessarily reside with the organization using the services provided by the VM.
Conversely, the virtual machine instances, themselves, may be acting as clients of a thirdparty service. Once again, the VMs could be launched, or moved, anywhere at any time and
each new instance must have connectivity to the third-party service just as if it were the one
and only original client of that service. For example, a client application running in a VM on a
particular host might be relying on a connected Luna SA to provide cryptographic services.
When the original host shows signs of failing and the VM is moved to another host, the Luna
SA should not notice when the VM is moved if the operation of the client application is to be
maintained; neither should the application running in the VM. The Luna SA should neither
know, nor care, that its assigned client VM is moving (or not); the crucial concern is that that
the SA knows it is always talking to the right VM.
The threat of an unauthorized VM clone gaining illicit network access to a Luna SA arises
out of the portability and reproducibility of VMs in general. This potential threat would entail
the attacker exploiting known or discovered vulnerabilities to gain control of the hypervisor
infrastructure, as well as cloning a significant portion of protected memory on the host.
Securing Luna HSM Connections in Virtual Environments Whitepaper
3
Luna HSM Server virtual clients
no instance-specific protection
Application Servers
in VMs, under control
of hypervisor
Luna HSM Server
(HSM inside)
Client in VM instance
SSL
SS
L
Network Trust Link
Attacker
If allowed access to file
system or (worse) to hypervisor,
can secretly copy VM instances
Luna HSM Server admin
(SSH or serial connection)
Admin links and accounts secured
by password or certificate
Clone of client VM
includes NTL cert
Securing Luna HSM Connections in Virtual Environments Whitepaper
4
Virtual Machines in many cloud environments are 100% isolated from their physical
environment and no physical attribute (not a TPM, nor a CPU ID, nor a MAC address) can be
used to lock down a VM or create a strongly-bound identity for one. On the other hand, cloudservice metadata, for example, is generally easily spoofed, and by itself would provide, at best,
a weak-link-securing characteristic.
To protect against potential attacks, such as the one illustrated above, and to continue to offer
“defense in depth,” SafeNet has developed the Host Trust Link (HTL) protocol. HTL, with its
innovative one-time token (OTT) 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
instance, regardless of where that physical VM instantiation resides. The NTL service is
still used, with some new options for the identifier in the client certificate, and the new HTL
verification layer is added.
HTL satisfies the four identified security objectives by:
• Ensuring that a stored VM image, containing NTL credentials, cannot be cloned to
establish an unauthorized NTLS connection to the Luna HSM server.
• Providing protection against cloning attacks after the VM binding has been established in
a running VM instance.
• Protecting the secrecy of the data used to protect the HTL link, and ensure it cannot be
spoofed or re-used, by maintaining it only in RAM and, thereby, greatly reducing the risk of
an attack.
How It Works
To assist in the efficient setup of clients in VM/cloud environments, it is possible to preconfigure NTLS credentials for a VM image with the certificate Common Name being one
that can be conveniently recognized within the specific environment (for example, unique IP
addresses, if possible, or hostname). The client certificate for the VM (also referred to as the
‘permanent certificate’) can be registered with the appropriate Luna SA, and the VM can be
assigned to the applicable HSM partition prior to instance start-up. The NTLS credentials
can then be automatically provided to the VM instance as it is launched to allow it to make an
initial connection to the assigned Luna SA.
When the VM instance starts up as a Luna SA client, the Luna client software will establish an
NTL connection with the serving Luna SA using the provisioned private key and certificate. The
Luna SA, with HTL binding enabled, will require the establishment of a Host Trust Link before
allowing an operational NTL connection to be made. The HTL protocol provides the means to
verify that it is an authorized VM instance attempting to connect to the Luna SA.
The HTL protocol requires a one-time token (OTT) from the Luna SA HSM, generated
specifically for that client instance, to be used to establish the operational HTL connection
and to authenticate the ongoing validity of that connection. The OTT is provided out-of-band
(possibly along with the permanent credentials delivered when the instance starts) and, with
proper external verification of instance startup, the OTT prevents an attacker from cloning
a VM at rest and using the cloned image to connect to the Luna HSM. It also prevents an
attacker from taking a static “snapshot” of the running instance and using it to connect from
an unauthorized platform.
As part of the HTL start-up, a temporary private key and certificate, bound to the IP address
of the connected instance, are securely delivered via HTL using the original NTL credentials.
Securing Luna HSM Connections in Virtual Environments Whitepaper
5
Once the temporary credentials are received, the original HTL connection is closed and a new
operational connection using the temporary credentials is opened.
Once the VM is started and the HTL link is active, it might be possible for an attacker to make a
complete copy of a running VM instance, in an attempt to impersonate the original client. The
following protections mitigate potential concerns with respect to the provider security:
• Binding to IP: The operational HTL connection binds the authorized VM instance to one
IP address. If a copied instance attempts to connect from a different IP address, it will
be unable to use the HSM. If a copy is made and assigned the same IP address, either
the original instance would have to be killed (a noticeable event) or there would be
network collisions (also detectable). Also, because the private key and certificate for the
operational HTL connection are stored in RAM only, the rogue copy would have to contain
a copy the RAM allocated to the Luna client software to be successful. This, in itself, could
render the attack infeasible in many environments.
• TLS-encrypted communications: All HTL counter values and synchronization packets
are sent over a TLS-protected connection using credentials that are unique to that
connection. 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.
• HTL synchronization code: Before HTL starts, the OTT is delivered out-of-band to the
Luna client software and it must be verified by the Luna SA in order to enable the HTL
connection. It is then discarded and never used again. Once the TLS-protected HTL is
established, a random start value and a random increment value are delivered to the
client via HTL. These are the basis for the ongoing secure “heartbeat” (synchronization
code) that maintains the connection’s authorization. The synchronization code provides
protection against:
• replay by unauthorized VM instances attempting to duplicate network traffic to
connect to the Luna SA, and
• a rogue VM attempting to connect using an old OTT
• There is a pre-configured OTT update period that can allow the authorized instance to reestablish its HTL connection after a brief outage or loss of connection without requiring
a new OTT from SA. The length of this period is configured by the HSM administrator,
with the default set to one (1) minute. Administrators can lengthen the time for improved
service 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, ANY attempt by an attacker to use a copy of the VM to connect
(no matter how it was obtained) will be rejected by the HSM unless the HSM receives a onetime token that is valid for the connection. In addition, for an attack to succeed once a VM has
been launched, the rogue VM’s counter and increment would need to be adjusted to match
those of the originally authorized VM by copying the values from the original VM’s allocated
RAM. This attack might be possible, but the use of a random initial counter value, a random
increment, and the ongoing synchronization between the client and the Luna SA present a
significant barrier to overcome by forcing the attacker to find the counter value in RAM rather
than simply using a known starting value, for example.
Securing Luna HSM Connections in Virtual Environments Whitepaper
6
Luna HSM Server virtual clients WITH
instance-specific (HTL) protection
Application Servers
HTL imposes a random-interval
synchronization requirement,
with a random starting time,
keyed to the specific client
instance and no other.
in VMs, under control
of hypervisor
Luna HSM Server
(HSM inside)
Client in VM instance
HOST TRUST LINK
Network Trust Link
SSL
(Cannot start until HTL is running)
Attacker
lacks data
and time
SS
*
L
HTL exists in memory only, not on
client hard disk
Attacker
If allowed access to file
system or (worse) to hypervisor,
can secretly copy VM instances
An attacker might
have stolen the VM instance,
but has no acces to the
critical HSM stored keys.
The Host Trust Link (HTL)
helps maintain the
valueof
the HSM trust
Clone of client VM
includes NTL cert
anchor investment.
Luna HSM Server admin
(SSH or serial connection)
Admin links and accounts secured
by password or certificate
*
An attacket cloning a non-operating
client VM gets (at best) an
outdated one-time token and
no synchronization info.
Cloning an operating VM still misses
synch data, unless the attacket has
hypervsior console access and clones
VM memory as well. Even in that
extreme security lapse, the window to
lanch the client clone and manually
synchronize HTL is very small or zero.
Securing Luna HSM Connections in Virtual Environments Whitepaper
7
Additional Safeguards
Random data used in generating one-time tokens is derived from the HSM’s FIPS-validated
Deterministic Random Bit Generator (complies with NIST SP 800-90 Counter Mode DRBG
specification), assuring the highest quality input to the process.
If a client requires VM binding, and an existing HTL link for that client goes down, the HSM
server kills all existing NTL connections from that client. This action occurs immediately and is
independent of the grace period (if any).
HTL in Non-Virtual Environments
HTL is being introduced because there is a pressing need to control a client’s ability to
connect to Luna SA in a virtual environment. HTL can, however, also help in traditional physical
environments. Customers may be concerned, for example, that an attacker could obtain a
copy of the NTL private key file from a physical computer platform and use it to connect to a
Luna SA from a rogue platform (despite the IP address collision issues discussed earlier in
relation to HTL). HTL can help to address that concern by greatly reducing the reliance on the
permanently stored private key and certificate alone to authenticate the client platform. By
introducing the additional verification step required to authorize the HTL connection using
the one-time token and issue the temporary credentials, along with the ongoing validation of
the connection, HTL gives greater control to the legitimate platform owner and reduces the
opportunity for an attacker to gain access from a rogue platform.
New Opportunities, New Threats – Evolved Protection
A few simple questions might spring to mind at this point. For example, why introduce this new
feature at all? Was the existing security provided by the Network Trust Link lacking something?
Are the controls provided by VM management systems and by cloud service providers not
adequate? How does it impact existing Luna SA customers? And what benefit does it bring to
new customers – in the cloud service provider role and in the consumer role? The following
section will address these questions.
Reasons for Introducing HTL
The earlier description of the HTL feature, and the ways in which it addresses many of the
concerns associated with operation in a virtual environment, has already touched on most of
the reasons behind the introduction of HTL. This section will summarize the reasons and provide
more insight into why the major elements of HTL were introduced into the overall product design.
First of all, there was a recognition that connections to Luna SA in a virtual environment
would not be the same as in the traditional physical environment. There are several important
differences between the two environments that make it difficult to maintain the same level
of assurance in the identity of the connecting virtual client compared to a non-virtual one.
The differences arise directly from the characteristics of virtual computing that make it so
attractive – flexibility, portability, and scalability.
To achieve these beneficial characteristics, virtual machines are, by necessity, not tied to
any physical server and, furthermore, are usually completely isolated from their physical
environments. In fact, the running VM typically does not have any visibility into characteristics
of the physical machine that might be used to associate it with a particular server. This means
that, in most cases, there are no reliable attributes (in the sense that they are permanently
associated with the environment in which the VM instance is running and not easily spoofed)
that are accessible and can be used to distinguish one instance of a VM from another.
The NTL connection between a Luna SA client and the Luna SA relied on the fact that the IP
address of a network host could be directly associated with a physical characteristic of the
host that was not easily spoofed – for example, the MAC address of the network interface
card. That direct physical relationship no longer exists for virtual machine hosts and the use
of the IP address to permanently identify a Luna SA client is not only unreliable in a virtual
environment, it might not be feasible in many situations.
Securing Luna HSM Connections in Virtual Environments Whitepaper
8
Cloud service provider environments and enterprise VM environments enforce controls
to maintain the separation of virtual machines that share a common physical server at
any point in time. Their customers (whether commercial or user departments within an
enterprise) demand the strict separation of virtual machine instances for very good reasons
– for example, processing non-interference and protection of data from illicit or inadvertent
sharing. SafeNet expects that these same customers will insist on a similar strict separation
between the cryptographic services used by their virtual machine instances and those
associated with other hosted instances. The introduction of HTL provides the control needed
to ensure that separation.
HTL not only allows new and existing customers to exercise control over client connections
in a virtual environment, it enhances connection control in traditional client-server
environments. The capability provided by the HTL one-time token to prevent connections from
unauthorized VM instances can also be used to prevent a rogue client from connecting using
a copy of the private key file from a legitimate client platform. This alleviates the concern
expressed by some customers that an attacker could connect to the appliance using a stolen
private key file.
SafeNet Luna SA HSMs are ready to serve customers’ cryptographic requirements in the
dynamic virtual machine and cloud-based infrastructures that characterize today’s IT
environment. And they are ready to provide service in these demanding environments in a way
that maintains SafeNet’s commitment to delivering the best in security and
operational effectiveness.
Securing Luna HSM Connections in Virtual Environments Whitepaper
9
Acronyms and Definitions
Acronym
Definition
HSM
•Hardware Security Module – a specialized computing device that performs cryptographic
operations and includes security features to protect keys and objects within a secure
hardware boundary, separate from any attached host computer or network device.
HTL
•Host Trust Link – a secure link that binds a client instance with an HSM server.
Hypervisor
•The controlling entity of a virtual machine (VM) system – maintains and manages the
various hosted operating system environments and their interactions with the underlying
hardware on which the entire system runs.
MAC
•Media Access Control -usually refers to a MAC address that is a unique identifier of a
network interface for communications on the physical network.
NTL
•Network Trust Link – a certificate-protected secure link between a Luna HSM appliance
and a client.
NTLS
•Network Trust Link Service – the service running on the HSM server that creates and
maintains the NTL with a client.
OTT
•One-Time Token – a special secret that is created for limited-time use to secure the
binding of an HSM to a specific instance of a client. An OTT is created on the HSM side,
using random data from the HSM’s hardware RNG.
RAM
•Random Access Memory – computer/device working memory, directly addressable,
usually volatile (contents disappear when power is removed); contrast with permanent
bulk storage like a hard disk.
RNG
•Random Number Generator – a device that gathers entropy data from various
sources and manipulates it to produce random or pseudo-random numbers for use in
cryptographic and statistical calculations.
TLS
•Transport Layer Security -a TCP/IP network security protocol and successor to Secure
Sockets Layer (SSL).
TPM
•Trusted Platform Module – an integrated circuit used in some computer systems to
secure certain information or to constrain hardware and software that can be used
with the protected computer. TPMs follow the protocol advanced by the Trusted
Computing Group.
VM
•Virtual Machine – a computing environment instance simulated within a computer
system that can host multiple such environments simultaneously, under the control
of a hypervisor. The simulated environments can be different operating systems or
OS versions, as desired. The supervising system maintains complete separation of
the hosted environments and also provides a layer of abstraction between the hosted
environments and the physical hardware (memory, ports, CPU, etc.) on which they reside.
Each virtual environment appears to have exclusive use of the resources of the host
system, is unaware of the other environments hosted on that system, and cannot touch
working data that is exclusive to those other environments.
Contact Us: For all office locations and contact information, please visit www.safenet-inc.com
Follow Us: www.safenet-inc.com/connected
©2013 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet.
All other product names are trademarks of their respective owners. WP (EN)-04.03.2013
Securing Luna HSM Connections in Virtual Environments Whitepaper
10