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

  • 4,595 views
Uploaded on

Traditionally, a local connection, such as SCSI or PCI bus, has been used to connect an HSM to …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to like this
No Downloads

Views

Total Views
4,595
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
158
Comments
1
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Securing Network-Attached HSMs:The SafeNet Luna SA Three-LayerAuthentication ModelWHITE PAPERTable of ContentsIntroduction ........................................................................................................................... 2Luna SA Overview ................................................................................................................... 3Luna SA System Components ................................................................................................ 3K6 Cryptographic Engine ........................................................................................................ 4HSM Partitions ....................................................................................................................... 4Network Trust Links (NTL) ...................................................................................................... 5Secure Command Line Interface (SCLI) .................................................................................. 5Trusted Path Authentication ................................................................................................... 5Direct Access to the Luna SA .................................................................................................. 5SSL Client and Server Authentication ..................................................................................... 6Three Layers of Authentication ............................................................................................... 6 Layer 1 — HSM Partition Activation ......................................................................... 7 Layer 2 — Network Trust Link (NTL) Activation ......................................................... 7 Layer 3 — Process-level Passwords ........................................................................ 8Frequently Asked Questions about Luna SA Authentication ................................................... 8Conclusion ............................................................................................................................. 9Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 1
  • 2. IntroductionIn the security world, the phrase ‘secure network’ is often viewed as an oxymoron; experiencehas demonstrated that once a device is connected to a network it becomes vulnerable toattacks from anyone who has access to that network. The fundamental cause of this lies at theheart of the TCP/IP (Transmission Control Protocol/Internet Protocol) used to communicateover the network — TCP/IP is a lightweight, open protocol specifically designed to facilitateeasy communication between disparate computers. This easy connectivity was desirable whenthe Internet consisted of a few small nodes located on University campuses and governmentresearch facilities, but in today’s connected world you can never be sure who might be lurking onthe other end of a network connection.However, the advantages gained through the simplified connectivity offered through modernnetworks cannot be denied, as exemplified by the explosion of office LANs and the globalphenomenon of the Internet in the last decade. As the popularity of networks has grown, so hasthe sophistication of computer security technologies to protect them from malicious attack.Today, computers connected to networks are defended with multiple layers of security, includingfirewalls, virus scanners, VPN remote access, and SSL-secured web sessions.SafeNet has established its reputation as the leading hardware security module (HSM) vendorby providing rock-solid security hardware. Since 1996, the Luna family of HSM products hasbeen used by hundreds of organizations in government, military, financial, healthcare, and largeenterprise sectors as the trusted solution to secure PKI applications. Working closely with ourcustomers, it became clear that there was a strong need for HSM products that offered thesecurity of traditional local-attached (e.g., SCSI, PCI) HSMs, while capturing the flexibility ofnetwork-attached devices. In response to changing market demands and an increasing shift tonetwork-delivered applications, SafeNet began researching the feasibility of a network-attachedHSM, 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 traditionalHSM 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 thistype of connection provides intrinsic physical security, it severely limits the scope and flexibilityof 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 commonEthernet cabling using standard TCP/IP for communications.Freed from the restrictions imposed by the local bus, the Luna SA is accessible to authenticatedclients that have access to the network. A single Luna SA can be shared between multipleclients and applications quickly and easily, drastically reducing integration, deployment, andmanagement overhead. The Luna SA’s comprehensive multi-layer security, built-in security BestPractices, and integrated FIPS 140-2 Level 3-validated cryptographic engine ensures the samesecurity as a traditional local-attached HSM while providing the power and flexibility of networkdeployment.Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 2
  • 3. Luna SA OverviewThe Luna SA is an Ethernet-attached HSM, designed to protect critical cryptographic keys andaccelerate sensitive cryptographic operations across a wide range of security applications. TheLuna SA includes many features that increase security, connectivity, and ease-of-administrationin dedicated and shared security applications.HSMs, in general, are designed to provide dedicated cryptographic functionality, including keygeneration, key storage, and digital signing, on a one-to-one basis to their host applications. Forexample, a database server using an HSM would require one HSM, and a secure website usingSSL on the same network might require a second HSM. As the number of secure applicationsrequiring an HSM grows, so does the number of HSMs deployed. As an Ethernet-attacheddevice, the Luna SA can be shared among many applications on a network; rather than requiringmany HSMs to fulfill application security demands, one Luna SA can be shared among manyapplications simultaneously.To increase its flexibility over traditional HSMs, the Luna SA was designed as an HSM that can beshared between multiple applications or clients connected to it through a network. In the sameway that mail and web servers provide email or web pages to authenticated clients, the LunaSA offers powerful key management and high-performance cryptographic processing to clientson 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 beshared between network clients.The Luna SA also introduces the concept of HSM partitions, a feature that allows the Luna SA’ssingle physical HSM to be divided into several logical HSM partitions, each with independentdata, access controls, and administrative policies. HSM partitions allow separate data storageand administration policies to be maintained by multiple applications sharing one Luna SAwithout fear of compromise from other partitions residing on it.Luna SA System ComponentsThe following block diagram is a conceptual overview of the Luna SA appliance depicting internalsystems, 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 EngineThe Luna SA’s integrated K6 Cryptographic Engine is a dedicated HSM used to performcryptographic operations and provide secure storage for sensitive cryptographic keys. The K6Cryptographic Engine provides the Luna SA’s HSM functionality, offering secure cryptographicstorage, cryptographic acceleration (over 6000 1024-bit RSA signings per second), administrativeaccess 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 AccessApplication Authentication SSL CAPI/CNG Partition 1 Partition 2... ...Partition 20The K6 Cryptographic Engine can also be used in conjunction with the optional Trusted Pathfeature to provide FIPS 140-2 Level 3-validated HSM operation.HSM PartitionsHSM partitions are independent logical HSMs that reside within the Luna SA’s K6 CryptographicEngine. Each HSM partition has its own data, access controls, and security policies, independentfrom other HSM partitions. The Luna SA can contain up to 20 HSM partitions, and each partitioncan 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 K6Cryptographic Engine’s ‘vault’. The vault itself offers an extremely high level of security for all thecontents inside, while the safety deposit boxes protect their specific contents from people whohave access to the vault. Each HSM partition has its own security and access controls to ensurethat 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, witheach HSM p having the capacity to hold up to 80 data objects (e.g., 80 digital certificates, or 40key-pairs). HSM partitions can be dedicated to a single Client, or multiple Clients that shareaccess to a single HSM partition.ClientsClients are applications, or application servers, that connect to the Luna SA to use its HSMcapabilities. Examples of possible clients are an encrypted database, a secure web server, or aCertificate Authority (CA); all these applications require the storage of sensitive cryptographicdata or they can benefit from the increased security and cryptographic performance offered bythe Luna SA.Each Client is assigned to one or more specific HSM partitions. Clients communicate withHSM partitions on the Luna SA through Network Trust Links (described in detail below), andauthenticate 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—NTLNetwork Trust Links (NTL) are secure, authenticated network connections between the Luna SAand Clients. NTLs use SSL with client authentication to protect all communications betweenHSM 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—SCLIThe Luna SA includes the Secure Command Line Interface (SCLI) for administration andmanagement of the Luna SA, including the registration and administration of HSM partitions,creation of NTLs, Backup (optional), and HSM policy management, and other administrativefunctions.The SCLI creates a secure administration channel for administrative sessions to preventunauthorized access or snooping. The SCLI is accessible either through a Direct AdministrationConnection through the Luna SA’s local Console Port, or it can be accessed remotely through aNetwork Administration Connection across a network connection.Alternatively, one of the Luna SA’s two standard Ethernet ports can be configured as a dedicatedadministration connection on a separate, secure network.Trusted Path Authentication (optional)The Luna SA features optional Trusted Path Authentication for users who wish to operate theirLuna SA in FIPS 140-2 Level 3 mode. Trusted Path Authentication augments the Luna SA’sauthentication controls with two-factor HSM authentication.True two-factor, trusted path authenticationrelies on the addition of the Luna PED (PIN EntryDevice), a handheld authentication console usedtogether with role-splitting PED keys (smallkey-shaped electronic identification tokens). Foradded security, Luna PED offers an optional Mof N authentication feature, whereby multiplepeople, each possessing an M of N PED key, areeach required to authenticate themselves withtheir unique PED key before any actions can beperformed.Direct Access to the Luna SAAs with other aspects of a comprehensive securityarchitecture, the Luna SA, and access to datastored on the K6 HSM contained within it, is protected by a number of different means to providein-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 SAand its internal HSM provides a high degree of confidence that cryptographic material within theHSM will not be compromised. Customers with extremely demanding security requirements canenhance the already strong security of the Luna SA by choosing appropriate installation, HSMconfiguration, and policy options.SSL Client and Server AuthenticationSSL is used in the Luna SA’s NTL architecture to establish a trusted channel between theNetwork 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 SSLprotocol. Any application running a NTLA on a client computer can be connected to the NTLS viaa 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 theHSM.Since access to the NTLS does not provide access to key material and sensitive functions on theHSM, compromise of an authorized client’s SSL private key does not pose a risk to the securityof key material in the HSM. If necessary, the Luna SA administrator can easily revoke the NTLSaccess 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 clientsAn attacker must have, at a minimum, logical network access to steal the private key andcertificate in order to move them to another platform. Physical access is necessary to make thenetwork configuration changes needed on each client in order to masquerade as the legitimateclient on the network.Control the applications permitted to run on the application serverMalicious 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 EthernetcableIf the Luna SA is dedicated to one client, a direct connection between the Luna SA and client ispossible.Three Layers of AuthenticationThe Luna SA uses a comprehensive three-layer authentication and access control model toachieve extremely strong security between the host application processes and the Luna SA’sHSM 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 SAto offer network connectivity to clients without sacrificing the security requirements of HSMoperations. 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 SystemLayer 1 — HSM Partition ActivationAll HSM partitions within the K6 remain inaccessible to clients until the Luna SA administratorlogs on and explicitly activates an HSM partition. HSM activation requires authentication with apassword, or if optional Trusted Path Authentication is in use, the presentation of the partitionowner’s PED Key and entry of a PIN code.Layer 2 — Network Trust Link (NTL) ActivationLayer 2 ensures that only registered and authenticated client computers are permitted access tothe Luna SA across a network through the NTL Service (NTLS) running on the Luna SA. There areseveral steps required to create NTLs:Client RegistrationBefore an application can connect to the Luna SA, it must first be registered as an authorizedclient. The client registration process requires the generation of a self-signed certificate on theclient computer that is bound to the client’s host name or IP address. Conversely, each Luna SAcontains its own certificate created when the Luna SA is first configured.Certificate ExchangeOnce the client has created their certificate, the client and Luna SA exchange certificates via asecure, encrypted file transfer process.Certificate RegistrationAfter the certificates are transferred, the Luna SA’s administrator registers the client certificateagainst the specific HSM partition (or partitions) that the client is allowed to access on theclient, the Luna SA’s certificate is also registered to create an exclusive relationship with aspecific Luna SA.Once this process is complete, the client can start an NTL session with the Luna SA andhave visibility of (but not yet access to) the HSM partitions it is registered and authorized toaccess; other HSM partitions present on the Luna SA for which the client is not registered areinaccessible 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 PasswordsLayer 3 provides process-level access control within an NTL-registered machine to a specifiedHSM partition. To gain access to data within an HSM partition, an application process runningon the client must first provide an HSM partition password to the Luna SA. This passwordis generated during the creation of the HSM partition, and if using the optional Trusted PathAuthentication feature, is provided to the HSM Partition owner application via an out-of-bandpath (the Luna PED handheld authentication console). The NTL Agent running on the host thencombines 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 fromthe HSM to form a unique response, which cannot be reversed by an attacker attempting toeavesdrop on the NTLA-to-NTLS connection.This one-time access token is sent to the HSM partition via the secure NTL. However, as theNTL 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 passwordvia the appropriate API’s call, and the additional security provided by the one-time challengemechanism is internal to the NTL.The Luna SA can be configured to have the activation state persistent (auto activation), allowingjust the challenge-response scheme to be used for login in the future, or it can be configured ina way that requires manual challenge interaction for every login. Typically, the process will bestarted 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 AuthenticationHow does the Luna SA maintain private key security?The Luna SA is, first and foremost, an HSM designed to protect sensitive private keys fromcompromise or unauthorized use. To achieve this goal, the Luna SA includes an integratedthird 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 andauthorization 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 keysand sensitive cryptographic operations are protected exclusively within its secure hardware andare 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 thenetwork?In a network environment, TCP/IP makes it very easy to connect to an unprotected networkdevice. Improperly configured network services running on a device may leave undesired openports, or permit anonymous connections that present hackers with potential vulnerabilities toexploit. To prevent unauthorized connections from the network, the Luna SA is locked down – allunnecessary ports are closed and unneeded services are removed. More importantly, the LunaSA features Network Trust Links (NTLs) to ensure that only trusted clients are able to connect toit. To further ensure the authenticity of NTLs, both the Luna SA and client must be specificallyregistered and have exchanged digital certificates with each other, requiring administrator-levelaccess 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 otherclients restricted?As a network-attached HSM, one of the Luna SA’s key benefits is the ability to share its HSMfunctionality to multiple network clients. To allow multiple clients to securely store data onone physical HSM, the Luna SA introduces HSM partitions, a feature that allows multipleindependent virtual HSMs to be hosted on one K6. HSM partitions each maintain their owndata and access control policies in protected memory partitions on the K6. Each client mustauthenticate to a specific HSM partition assigned to it by the HSM administrator. The data inother unassigned HSM partitions is inaccessible at all times. The use of HSM partitions allowsmultiple clients to maintain independent data on the Luna SA without fear of it being accessedby 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-layeraccess 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-securedadministration session across the network. Administrative access to the K6 HSM is controlledby another unique password, or with the optional Trusted Path Authentication, through the LunaPED, permitting FIPS 140-2 Level 3-validated two-factor, multi-person direct authentication tothe K6. Finally, each client must provide a unique password challenge token (PED key) beforethey can access or use key materials on the Luna SA. By requiring multiple strong passwords (ortokens) distributed among several people, the ability to gain entry through ‘brute force’ passwordattacks, or through insider attack, is eliminated.ConclusionTraditionally, a local connection, such as SCSI or PCI bus, has been used to connect an HSM toits host server. While these local connections provide good bandwidth and an added degree ofphysical security, they cannot offer the flexible, shareable features of a network connection. TheLuna SA was designed from the ground up to provide customers with a more powerful, flexibleHSM product. One of the cornerstones of this flexibility is the fact that the Luna SA is a networkattached device, a feature that permits the Luna SA’s high-performance HSM capabilities to beeasily 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 respectivelycontrol administrative, client, and application access. This three-layer model, coupled withmulti- level user authentication policies, integrated FIPS 140-2 Level 3-validated K6 HSM, andsecure software and hardware design, allows the Luna SA to offer the same high degree ofsecurity 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.comFollow 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.10Securing Network-Attached HSMs:The SafeNet Luna SA Three-Layer Authentication Model White Paper 9