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
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
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
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
Administration
Admin
Configuration DB
USB Backup Interface
Application JCA
SSL Network Trust Link Services (NTLS)
K6 Application CAPI/CNG
Local or Remote PED Access
Backup/ Key Export/CA4 (PKI Bundle) Luna Remote Backup HSM
Secure Authentication
SSL 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
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
• 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
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.
3
Process-Level Password C_Login “password” Password set by HSM Partition
Luna SA
NTL
Network Trust Link Service (NTLS)
Admin
Config DB Client #1 IP-10.0.0.2 Container-1.2
K6 CCE
X
1
HSM Partition Authentication
Container Container Container #1 #2 #N
2
NTL Activation 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
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
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 networkattached 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