Securing Network-Attached HSMs: The SafeNet Luna SA Three-Layer Authentication Model

Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 1

Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer

Authentication ModelWHITE 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


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 specifi cally 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 simplifi ed connectivity offered through modern networks cannot be denied, as exemplifi ed by the explosion of offi ce 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 fi rewalls, 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, fi nancial, 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 fl exibility 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 fl exibility 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 fl exibility of network deployment.


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 fulfi ll application security demands, one Luna SA can be shared among many applications simultaneously.

To increase its fl exibility 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)


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.

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 specifi c 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 confi guration, 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 certifi cates, 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 Certifi cate Authority (CA); all these applications require the storage of sensitive cryptographic data or they can benefi t from the increased security and cryptographic performance offered by the Luna SA.

Each Client is assigned to one or more specifi c 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 certifi cate and unique HSM partition challenge.

SSL

SSL

SSL

NetworkTrust Link Services(NTLS)

Configuration DB

K6

Admin

Partition 1 Partition 2... ...Partition 20

Application

Application

Application

PKCS #11

JCA

CAPI/CNG

Administration

Backup/

Key Export/CA4

(PKI Bundle)

Luna Remote

Backup HSM

Secure

Authentication

US

B B

ackup Interface

Luna SA

Local or Remote PED Access


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 confi gured 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 identifi cation 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 confi gured for maximum security.


The SSH (secure shell) service and NTLS are confi gured 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-defi ned 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 Offi cer role for HSM-wide confi guration 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 confi dence 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 confi guration, 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 certifi cate in order to move them to another platform. Physical access is necessary to make the network confi guration 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.


This three-layer authentication and access control model was designed to allow the Luna SA to offer network connectivity to clients without sacrifi cing the security requirements of HSM operations.

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 fi rst be registered as an authorized client. The client registration process requires the generation of a self-signed certifi cate on the client computer that is bound to the client’s host name or IP address. Conversely, each Luna SA contains its own certifi cate created when the Luna SA is fi rst confi gured.

Certifi cate Exchange

Once the client has created their certifi cate, the client and Luna SA exchange certifi cates via a secure, encrypted fi le transfer process.

Certifi cate Registration

After the certifi cates are transferred, the Luna SA’s administrator registers the client certifi cate against the specifi c HSM partition (or partitions) that the client is allowed to access on the client, the Luna SA’s certifi cate is also registered to create an exclusive relationship with a specifi c 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.

Luna SA - Authentication and Access Control System

X

Luna SA

NTL

NetworkTrust Link

Service(NTLS)

Config DB

Admin

K6 CCE

Container#1

Client #1IP-10.0.0.2Container-1.2

Container#2

Container#N

HSM Partition Authentication1

NTL ActivationUsing SSL Certificate Exchange2

Process-Level PasswordC_Login “password”Password set by HSM Partition

3


Layer 3 — Process-level Passwords

Layer 3 provides process-level access control within an NTL-registered machine to a specifi ed HSM partition. To gain access to data within an HSM partition, an application process running on the client must fi rst 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 confi gured 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 confi gured 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, fi rst 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 confi nes. 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 confi gured 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 specifi cally registered and have exchanged digital certifi cates with each other, requiring administrator-level access to both systems.


Contact Us: For all offi ce 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

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 benefi ts 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 specifi c 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 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.

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 sacrifi cing the fl exibility of a network-attached device.

Securing Network-Attached HSMs: The SafeNet Luna SA Three-Layer Authentication Model

Technology

Transcript of Securing Network-Attached HSMs: The SafeNet Luna SA Three-Layer Authentication Model