Traditionally, a local connection, such as SCSI or PCI bus, has been used to connect an HSM to its host server. While these local connections provide good bandwidth and an added degree of physical security, they cannot offer the fl exible, shareable features of a network connection. The Luna SA was designed from the ground up to provide customers with a more powerful, fl exible HSM product. One of the cornerstones of this fl exibility is the fact that the Luna SA is a network attached device, a feature that permits the Luna SA’s high-performance HSM capabilities to be easily deployed and shared between multiple network clients.

1. Securing Network-Attached HSMs:
The SafeNet Luna SA Three-Layer
Authentication Model
WHITE PAPER
Table of Contents
Introduction ........................................................................................................................... 2
Luna SA Overview ................................................................................................................... 3
Luna SA System Components ................................................................................................ 3
K6 Cryptographic Engine ........................................................................................................ 4
HSM Partitions ....................................................................................................................... 4
Network Trust Links (NTL) ...................................................................................................... 5
Secure Command Line Interface (SCLI) .................................................................................. 5
Trusted Path Authentication ................................................................................................... 5
Direct Access to the Luna SA .................................................................................................. 5
SSL Client and Server Authentication ..................................................................................... 6
Three Layers of Authentication ............................................................................................... 6
Layer 1 — HSM Partition Activation ......................................................................... 7
Layer 2 — Network Trust Link (NTL) Activation ......................................................... 7
Layer 3 — Process-level Passwords ........................................................................ 8
Frequently Asked Questions about Luna SA Authentication ................................................... 8
Conclusion ............................................................................................................................. 9
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 1

2. Introduction
In the security world, the phrase ‘secure network’ is often viewed as an oxymoron; experience
has demonstrated that once a device is connected to a network it becomes vulnerable to
attacks from anyone who has access to that network. The fundamental cause of this lies at the
heart of the TCP/IP (Transmission Control Protocol/Internet Protocol) used to communicate
over the network — TCP/IP is a lightweight, open protocol specifically designed to facilitate
easy communication between disparate computers. This easy connectivity was desirable when
the Internet consisted of a few small nodes located on University campuses and government
research facilities, but in today’s connected world you can never be sure who might be lurking on
the other end of a network connection.
However, the advantages gained through the simplified connectivity offered through modern
networks cannot be denied, as exemplified by the explosion of office LANs and the global
phenomenon of the Internet in the last decade. As the popularity of networks has grown, so has
the sophistication of computer security technologies to protect them from malicious attack.
Today, computers connected to networks are defended with multiple layers of security, including
firewalls, virus scanners, VPN remote access, and SSL-secured web sessions.
SafeNet has established its reputation as the leading hardware security module (HSM) vendor
by providing rock-solid security hardware. Since 1996, the Luna family of HSM products has
been used by hundreds of organizations in government, military, financial, healthcare, and large
enterprise sectors as the trusted solution to secure PKI applications. Working closely with our
customers, it became clear that there was a strong need for HSM products that offered the
security of traditional local-attached (e.g., SCSI, PCI) HSMs, while capturing the flexibility of
network-attached devices. In response to changing market demands and an increasing shift to
network-delivered applications, SafeNet began researching the feasibility of a network-attached
HSM, resulting in the development of the technologies that underpin the Luna SA.
With the introduction of the Luna SA Network HSM, SafeNet has radically altered the traditional
HSM deployment model. Earlier HSMs have been limited by their use of a local host connection,
such as the internal PCI or external SCSI bus, for connectivity to their host computers. While this
type of connection provides intrinsic physical security, it severely limits the scope and flexibility
of deployment due to its requirement for a direct, one-to-one attachment to a host. In contrast,
the Luna SA is a stand-alone network appliance that connects to its clients across common
Ethernet cabling using standard TCP/IP for communications.
Freed from the restrictions imposed by the local bus, the Luna SA is accessible to authenticated
clients that have access to the network. A single Luna SA can be shared between multiple
clients and applications quickly and easily, drastically reducing integration, deployment, and
management overhead. The Luna SA’s comprehensive multi-layer security, built-in security Best
Practices, and integrated FIPS 140-2 Level 3-validated cryptographic engine ensures the same
security as a traditional local-attached HSM while providing the power and flexibility of network
deployment.
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 2

3. Luna SA Overview
The Luna SA is an Ethernet-attached HSM, designed to protect critical cryptographic keys and
accelerate sensitive cryptographic operations across a wide range of security applications. The
Luna SA includes many features that increase security, connectivity, and ease-of-administration
in dedicated and shared security applications.
HSMs, in general, are designed to provide dedicated cryptographic functionality, including key
generation, key storage, and digital signing, on a one-to-one basis to their host applications. For
example, a database server using an HSM would require one HSM, and a secure website using
SSL on the same network might require a second HSM. As the number of secure applications
requiring an HSM grows, so does the number of HSMs deployed. As an Ethernet-attached
device, the Luna SA can be shared among many applications on a network; rather than requiring
many HSMs to fulfill application security demands, one Luna SA can be shared among many
applications simultaneously.
To increase its flexibility over traditional HSMs, the Luna SA was designed as an HSM that can be
shared between multiple applications or clients connected to it through a network. In the same
way that mail and web servers provide email or web pages to authenticated clients, the Luna
SA offers powerful key management and high-performance cryptographic processing to clients
on the network. To achieve this, the Luna SA includes an integrated FIPS 140-2- validated HSM,
the K6 Cryptographic Engine, which offers the same highlevel of security as traditional HSMs;
however, the Luna SA adds a secure service layer that allows the K6 Cryptographic Engine to be
shared between network clients.
The Luna SA also introduces the concept of HSM partitions, a feature that allows the Luna SA’s
single physical HSM to be divided into several logical HSM partitions, each with independent
data, access controls, and administrative policies. HSM partitions allow separate data storage
and administration policies to be maintained by multiple applications sharing one Luna SA
without fear of compromise from other partitions residing on it.
Luna SA System Components
The following block diagram is a conceptual overview of the Luna SA appliance depicting internal
systems, communications, and interaction with application servers:
1. K6 Cryptographic Engine
2. Clients
3. HSM Partitions
4. Network Trust Links (NTL)
5. Secure Command Line Interface (SCLI)
6. Trusted Path Authentication (optional)
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 3

4. K6 Cryptographic Engine
The Luna SA’s integrated K6 Cryptographic Engine is a dedicated HSM used to perform
cryptographic operations and provide secure storage for sensitive cryptographic keys. The K6
Cryptographic Engine provides the Luna SA’s HSM functionality, offering secure cryptographic
storage, cryptographic acceleration (over 6000 1024-bit RSA signings per second), administrative
access control, and policy management.
Application
PKCS #11 SSL
Luna SA Admin
Administration
Configuration DB
Backup/
USB Backup
Interface
Key Export/CA4
(PKI Bundle)
Application
JCA
SSL Network Luna Remote
Trust Link Backup HSM
Services
(NTLS)
K6 Local or Remote Secure
PED Access
Application Authentication
SSL
CAPI/CNG Partition 1 Partition 2... ...Partition 20
The K6 Cryptographic Engine can also be used in conjunction with the optional Trusted Path
feature to provide FIPS 140-2 Level 3-validated HSM operation.
HSM Partitions
HSM partitions are independent logical HSMs that reside within the Luna SA’s K6 Cryptographic
Engine. Each HSM partition has its own data, access controls, and security policies, independent
from other HSM partitions. The Luna SA can contain up to 20 HSM partitions, and each partition
can be connected to one or more Clients. Each HSM partition has a special access control role,
called the Owner, who manages it.
HSM partitions can be thought of as ‘safety deposit boxes’ that reside within the K6
Cryptographic Engine’s ‘vault’. The vault itself offers an extremely high level of security for all the
contents inside, while the safety deposit boxes protect their specific contents from people who
have access to the vault. Each HSM partition has its own security and access controls to ensure
that only the rightful authorized owner of the partition can access the data contained inside.
Depending on the configuration, each Luna SA can contain 1 2 5 10, or 20 HSM partitions, with
each HSM p having the capacity to hold up to 80 data objects (e.g., 80 digital certificates, or 40
key-pairs). HSM partitions can be dedicated to a single Client, or multiple Clients that share
access to a single HSM partition.
Clients
Clients are applications, or application servers, that connect to the Luna SA to use its HSM
capabilities. Examples of possible clients are an encrypted database, a secure web server, or a
Certificate Authority (CA); all these applications require the storage of sensitive cryptographic
data or they can benefit from the increased security and cryptographic performance offered by
the Luna SA.
Each Client is assigned to one or more specific HSM partitions. Clients communicate with
HSM partitions on the Luna SA through Network Trust Links (described in detail below), and
authenticate to the Luna SA with a digital certificate and unique HSM partition challenge.
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 4

5. Network Trust Links—NTL
Network Trust Links (NTL) are secure, authenticated network connections between the Luna SA
and Clients. NTLs use SSL with client authentication to protect all communications between
HSM partitions on the Luna SA and its Clients.
NTLs consist of three parts:
• The Network Trust Link Server (NTLS) on the Luna SA
• Network Trust Link Agents (NTLA) installed on the Clients
• The Network Trust Link itself, a secure connection that is created between the NTLS and an
authenticated NTLA.
The Luna SA can support up to 800 simultaneous NTL connections.
Secure Command Line Interface—SCLI
The Luna SA includes the Secure Command Line Interface (SCLI) for administration and
management of the Luna SA, including the registration and administration of HSM partitions,
creation of NTLs, Backup (optional), and HSM policy management, and other administrative
functions.
The SCLI creates a secure administration channel for administrative sessions to prevent
unauthorized access or snooping. The SCLI is accessible either through a Direct Administration
Connection through the Luna SA’s local Console Port, or it can be accessed remotely through a
Network Administration Connection across a network connection.
Alternatively, one of the Luna SA’s two standard Ethernet ports can be configured as a dedicated
administration connection on a separate, secure network.
Trusted Path Authentication (optional)
The Luna SA features optional Trusted Path Authentication for users who wish to operate their
Luna SA in FIPS 140-2 Level 3 mode. Trusted Path Authentication augments the Luna SA’s
authentication controls with two-factor HSM authentication.
True two-factor, trusted path authentication
relies on the addition of the Luna PED (PIN Entry
Device), a handheld authentication console used
together with role-splitting PED keys (small
key-shaped electronic identification tokens). For
added security, Luna PED offers an optional M
of N authentication feature, whereby multiple
people, each possessing an M of N PED key, are
each required to authenticate themselves with
their unique PED key before any actions can be
performed.
Direct Access to the Luna SA
As with other aspects of a comprehensive security
architecture, the Luna SA, and access to data
stored on the K6 HSM contained within it, is protected by a number of different means to provide
in-depth security.
• Protection against physical tampering is provided on both the Luna SA and the internal K6
HSM.
• Unnecessary TCP ports and daemons are removed to prevent access through open ports
or unsecured services. Only SSH and NTLS services, supporting the SCLI and HSM server
features respectively, are running on the Luna SA. Both services are configured for maximum
security.
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 5

6. • The SSH (secure shell) service and NTLS are configured in a way that does not allow root
access.
• Both SSH and NTLS allow access to only the functions that are absolutely necessary
to perform the pre-defined legitimate administrative and user access operations – in
particular, there is no generic shell access.
• Access to the Luna SA’s administrative operations, either through SSH or serial terminal
connection, requires authentication to the administrator account.
• Access to destructive HSM commands (e.g., initialization) is only permitted via the
administration interface and is not permitted via the NTLA client interface. If Trusted Path
Authentication is used, HSM commands require separate two-factor authentication.
• Access to the HSM is separately controlled based on authentication to the appropriate HSM
partition or the Security Officer role for HSM-wide configuration operations.
The in-depth application of multiple layers of security at all levels of the interface to the Luna SA
and its internal HSM provides a high degree of confidence that cryptographic material within the
HSM will not be compromised. Customers with extremely demanding security requirements can
enhance the already strong security of the Luna SA by choosing appropriate installation, HSM
configuration, and policy options.
SSL Client and Server Authentication
SSL is used in the Luna SA’s NTL architecture to establish a trusted channel between the
Network Trust Link Agent (NTLA) running on the client and the Network Trust Link Server (NTLS)
within Luna SA using the mutual authentication and session encryption provided by the SSL
protocol. Any application running a NTLA on a client computer can be connected to the NTLS via
a NTL’s SSL link. However, due to the process-level password requirements laid out in Layer 3
(see page 10), this still would not allow an application on the client access to the contents of the
HSM.
Since access to the NTLS does not provide access to key material and sensitive functions on the
HSM, compromise of an authorized client’s SSL private key does not pose a risk to the security
of key material in the HSM. If necessary, the Luna SA administrator can easily revoke the NTLS
access of a comprimised or suspect client.
Customers can take additional steps to control access to private keys in their environments.
Depending on the nature of their operating environment, they can:
Control network and physical access to Luna SA clients
An attacker must have, at a minimum, logical network access to steal the private key and
certificate in order to move them to another platform. Physical access is necessary to make the
network configuration changes needed on each client in order to masquerade as the legitimate
client on the network.
Control the applications permitted to run on the application server
Malicious applications executed on a legitimate client can cause denial of service.
Directly connect the Luna SA to the application server platform using a cross-over UTP Ethernet
cable
If the Luna SA is dedicated to one client, a direct connection between the Luna SA and client is
possible.
Three Layers of Authentication
The Luna SA uses a comprehensive three-layer authentication and access control model to
achieve extremely strong security between the host application processes and the Luna SA’s
HSM partitions.
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 6

7. This three-layer authentication and access control model was designed to allow the Luna SA
to offer network connectivity to clients without sacrificing the security requirements of HSM
operations.
Process-Level Password
3 C_Login “password”
Password set by HSM Partition
Luna SA Admin
Config DB
Network
Client #1
Trust Link IP-10.0.0.2
NTL Service Container-1.2
(NTLS)
K6 CCE
X
Container Container Container
#1 #2 #N
1 HSM Partition Authentication
NTL Activation
2 Using SSL Certificate Exchange
Luna SA - Authentication and Access Control System
Layer 1 — HSM Partition Activation
All HSM partitions within the K6 remain inaccessible to clients until the Luna SA administrator
logs on and explicitly activates an HSM partition. HSM activation requires authentication with a
password, or if optional Trusted Path Authentication is in use, the presentation of the partition
owner’s PED Key and entry of a PIN code.
Layer 2 — Network Trust Link (NTL) Activation
Layer 2 ensures that only registered and authenticated client computers are permitted access to
the Luna SA across a network through the NTL Service (NTLS) running on the Luna SA. There are
several steps required to create NTLs:
Client Registration
Before an application can connect to the Luna SA, it must first be registered as an authorized
client. The client registration process requires the generation of a self-signed certificate on the
client computer that is bound to the client’s host name or IP address. Conversely, each Luna SA
contains its own certificate created when the Luna SA is first configured.
Certificate Exchange
Once the client has created their certificate, the client and Luna SA exchange certificates via a
secure, encrypted file transfer process.
Certificate Registration
After the certificates are transferred, the Luna SA’s administrator registers the client certificate
against the specific HSM partition (or partitions) that the client is allowed to access on the
client, the Luna SA’s certificate is also registered to create an exclusive relationship with a
specific Luna SA.
Once this process is complete, the client can start an NTL session with the Luna SA and
have visibility of (but not yet access to) the HSM partitions it is registered and authorized to
access; other HSM partitions present on the Luna SA for which the client is not registered are
inaccessible and not visible to the client.
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 7

8. Layer 3 — Process-level Passwords
Layer 3 provides process-level access control within an NTL-registered machine to a specified
HSM partition. To gain access to data within an HSM partition, an application process running
on the client must first provide an HSM partition password to the Luna SA. This password
is generated during the creation of the HSM partition, and if using the optional Trusted Path
Authentication feature, is provided to the HSM Partition owner application via an out-of-band
path (the Luna PED handheld authentication console). The NTL Agent running on the host then
combines the password with a unique one-time challenge.
The challenge secret is the equivalent of a password for per-process secondary authentication.
Once entered, it is combined inside the Luna SA client library with random one-time data from
the HSM to form a unique response, which cannot be reversed by an attacker attempting to
eavesdrop on the NTLA-to-NTLS connection.
This one-time access token is sent to the HSM partition via the secure NTL. However, as the
NTL connection itself employs SSL to encrypt communications between the client and Luna SA,
eavesdropping becomes impossible.
From the application’s point of view, the login is a normal process of providing a password
via the appropriate API’s call, and the additional security provided by the one-time challenge
mechanism is internal to the NTL.
The Luna SA can be configured to have the activation state persistent (auto activation), allowing
just the challenge-response scheme to be used for login in the future, or it can be configured in
a way that requires manual challenge interaction for every login. Typically, the process will be
started on the server and will then run continuously to provide the required services (CA, OCSP,
etc.). The challenge secret would only be entered at the time the process is started.
Frequently Asked Questions About Luna SA Authentication
How does the Luna SA maintain private key security?
The Luna SA is, first and foremost, an HSM designed to protect sensitive private keys from
compromise or unauthorized use. To achieve this goal, the Luna SA includes an integrated
third generation FIPS 140-2 Level 3-validated* HSM, the Chrysalis K6 Cryptographic Engine.
The K6 is a self-contained cryptographic processor, handling all key management, access and
authorization control, key storage, and key operations (e.g., key generation, digital signatures)
exclusively within its protected confines. As a dedicated HSM, the K6 ensures that private keys
and sensitive cryptographic operations are protected exclusively within its secure hardware and
are never exposed to the Luna SA’s system environment, or to the outside world.
What controls are implemented to prevent unauthorized access to the Luna SA from the
network?
In a network environment, TCP/IP makes it very easy to connect to an unprotected network
device. Improperly configured network services running on a device may leave undesired open
ports, or permit anonymous connections that present hackers with potential vulnerabilities to
exploit. To prevent unauthorized connections from the network, the Luna SA is locked down – all
unnecessary ports are closed and unneeded services are removed. More importantly, the Luna
SA features Network Trust Links (NTLs) to ensure that only trusted clients are able to connect to
it. To further ensure the authenticity of NTLs, both the Luna SA and client must be specifically
registered and have exchanged digital certificates with each other, requiring administrator-level
access to both systems.
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 8

9. If multiple clients connect to the Luna SA, how is access to keys or data belonging to other
clients restricted?
As a network-attached HSM, one of the Luna SA’s key benefits is the ability to share its HSM
functionality to multiple network clients. To allow multiple clients to securely store data on
one physical HSM, the Luna SA introduces HSM partitions, a feature that allows multiple
independent virtual HSMs to be hosted on one K6. HSM partitions each maintain their own
data and access control policies in protected memory partitions on the K6. Each client must
authenticate to a specific HSM partition assigned to it by the HSM administrator. The data in
other unassigned HSM partitions is inaccessible at all times. The use of HSM partitions allows
multiple clients to maintain independent data on the Luna SA without fear of it being accessed
by other registered or non-registered clients.
What access controls prevent unauthorized administration or use of the Luna SA?
In addition to the strict measures imposed by NTLs, the Luna SA also includes a multi-layer
access control policy to prevent unauthorized use of the Luna SA or keys stored on the K6. First,
the Luna SA administrator has a unique password (strict strong password rules are enforced)
and can only access the Luna SA via a direct local console port or through an SSH-secured
administration session across the network. Administrative access to the K6 HSM is controlled
by another unique password, or with the optional Trusted Path Authentication, through the Luna
PED, permitting FIPS 140-2 Level 3-validated two-factor, multi-person direct authentication to
the K6. Finally, each client must provide a unique password challenge token (PED key) before
they can access or use key materials on the Luna SA. By requiring multiple strong passwords (or
tokens) distributed among several people, the ability to gain entry through ‘brute force’ password
attacks, or through insider attack, is eliminated.
Conclusion
Traditionally, a local connection, such as SCSI or PCI bus, has been used to connect an HSM to
its host server. While these local connections provide good bandwidth and an added degree of
physical security, they cannot offer the flexible, shareable features of a network connection. The
Luna SA was designed from the ground up to provide customers with a more powerful, flexible
HSM product. One of the cornerstones of this flexibility is the fact that the Luna SA is a network
attached device, a feature that permits the Luna SA’s high-performance HSM capabilities to be
easily deployed and shared between multiple network clients.
The Luna SA’s three-layer authentication model includes separate HSM partition authentication,
2-way NTL network authentication, and process level application authentication to respectively
control administrative, client, and application access. This three-layer model, coupled with
multi- level user authentication policies, integrated FIPS 140-2 Level 3-validated K6 HSM, and
secure software and hardware design, allows the Luna SA to offer the same high degree of
security and performance as traditional HSMs without sacrificing the flexibility of a network-
attached device.
Contact Us: For all office locations and contact information, please visit www.safenet-inc.com
Follow Us: www.safenet-inc.com/connected
©2010 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)-12.09.10
Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 9