Introduction to PKI & SafeNet Luna

Hardware Security Modules

with Microsoft Windows

Overview
Certificate Services in Microsoft Windows Server products provide an
integrated Public Key Infrastructure (PKI) for use by a wide range of
Windows applications. This paper examines how the addition of a SafeNet
Luna Hardware Security Module (HSM) provides a higher level of security in
a Windows Server PKI deployment.

Introduction
To aid a successful and secure Public Key Infrastructure (PKI)
implementation, this article examines the essential concepts, technology,
components, and operations associated with deploying a Microsoft PKI with
root key protection performed by a SafeNet Luna Hardware Security Module
(HSM).

PKIA Critical Building Block in Computer Security

Solutions
In a world increasingly reliant on computers, computer networks, and digital
information to conduct business, devising ways to ensure the security of
electronic business transactions has taken on acute importance. Unlike
traditional business transactions, with face-to-face meetings and notarized
paper contracts, electronic transactions exist merely as a collection of 1s and
0s in computer files. Because of their intangible nature, details of these
electronic transactions can be stolen, misrepresented, manipulated, or
refuted by the people involved more readily than in the past.
The importance of a flexible, robust security system becomes apparent when
considering the problems with securing access controls and permission
management for an ever-growing network of computers, as well as concerns
over privacy and security on corporate networks and the Internet.

A flexible, robust security system needs to address the following security

issues:

Identity

Integrity

Privacy

Authentication

Access control

Non-repudiation

Fortunately, cryptographic technology offers a proven solutionasymmetric

key encryption and digital signatures within a PKI security framework.

Public Key Infrastructure Basics

Once the realm of superpower spy organizations, the Asymmetric Key
Encryption technology at the heart of a PKI is now commonly used to enforce
corporate, industry, and personal security in the electronic age.

PKI and Asymmetric Key EncryptionA Heritage of Trust

Asymmetric Key Encryption technology, and the Public Key Infrastructure
(PKI) umbrella that surrounds it, was born out of academic research and
Cold War necessity in the late 1960s to early 1970s. This intelligence has
evolved into business tools that solve the security problems inherent in
todays digital transactions. Along with the phenomenal growth in computing
power and network connectivity, sophisticated, strong encryption technology
is now attainable with a standard desktop computer.
PKI now spans the globe via computers linked to the Internet, helping users
shop safely online, verifying where email came from, controlling access to
files on a hard drive, and securing confidential records through encryption.
However, advanced cryptography and personal computing horsepower are
only the tip of the iceberg when deploying a PKI in a business environment.
The implementer of a PKI must give equal, if not greater, significance to
design, integration, physical security, and operational practices to ensure that
the PKI stays secure as intended.

Asymmetric Key Encryption

Without delving into the complex mathematics that make modern
cryptography possible, Asymmetric Key Encryption can be described as a
technique that allows two or more people who have never met to agree on a
cryptographic key that allows them to exchange a suitable set of encryption
keys for their message.

How It Works
Who exactly are Alice, Bob, and Charles? Just as Dick, Spot, and Jane were
invented to teach reading, cryptographers created Alice, Bob, and Charles to
illustrate encryption technology and its importance in the business world.
Alice and Bob represent individuals who wish to secure their
communications, while Charles represents an outside party who is
attempting to intercept private messages or deceive the other participants.
Each participant wishing to send a message creates two keys (a key pair)
that are different, but mathematically related. One of the two keys is a public
key, also called an encryption key, that can be freely shared and distributed;
the other is a private key, also called a decryption key, which is kept secret
and known only to the person who holds it.

The Functions of Asymmetric Key Encryption

Privacy through Encryption
When Alice wishes to send Bob a message, she encrypts the message with
Bobs public key (which is freely available) and sends it to Bob. When Bob
receives the message, he uses his secret private key to decrypt the
message. If the message were intercepted by Charles, who hopes to snoop
into Alice and Bobs business, he would be unable to decipher it. Although
Charles can easily look up Bobs public key, the message can be decoded
only with Bobs secret private key. Provided that Bobs encryption key is
large enough to prevent brute force decryption attacks, the privacy of the
message can be guaranteed because only the intended recipient can
decipher it.
However, although Alices email is secure, how does Bob know if Alice was
the actual sender? Because Bobs freely available public key is all that is
required to encrypt the message, Charles could easily compose a message
to Bob and make it appear to have originated from Alice. Asymmetric Key
Encryption offers a solution for this as well, called signing.
Signing Proves Identity
If Alice wants Bob to know for certain that she wrote the message, she can
choose to sign (encrypt) the email with her private key (that only she knows)
before encrypting it with Bobs public key. Imagine a digital envelope with
Bobs name on it wrapped around the signed message from Alice. When Bob
receives the message, he can remove the envelope by decrypting the
message contents with his private key; he can then decrypt the digital
signature on the signed message inside the envelope using Alices freely
available public key to verify Alices identity as the sender.
Because a signature can be decrypted by anyone with access to the signers
public key, it offers no privacy. However, a signed message does guarantee
that the sender is who they say they are. Because only Alices public key can
decrypt the signature created using Alices private key, Bob can be assured
that Alice wrote the message. If Charles attempts to forge an email from
Alice, Bob can easily discover it because the signatures will not match. With
signing, you can verify a persons identity in a transaction, provided that only
they know their private key.

Hashing for Message Integrity

What if Charles were to intercept and attempt to alter the email that Alice
sent to Bob? Another mathematical technique, called a hash or digest,
ensures that Charles deception can be easily spotted.
A hash is a simple procedure that is highly effective in thwarting Charles
efforts. A hash is a mathematical digest of the contents of the message,
creating a number that is unique to that message. A simple hash might
consist of assigning a number between 1 and 26 to each letter in the
alphabet and adding them all together to get a sum for the whole message.
Before Alice sends her message, she computes a hash of the message,
signs the hash with her private key, and includes the signed hash with the
body of the message she encrypted with Bobs public key. Once a hash is
generated and included with the message, any changes or additions to the
originally hashed message will be evident to Bob.
When Bob receives the message, he decrypts it, verifies the signature on the
hash, and applies the same hashing function to the decrypted message. If
the hash value that Bob receives from his decrypted message matches the
hash signed by Alice, the message has not been tampered with. If Charles
had modified the message in transit, the hash values would be different and
the deception exposed. In this way the hash serves to verify the integrity of
the message.

Cryptographic Security Functions

The use of Asymmetric Key Encryption and message digests forms the
foundation for security in todays Internet communications. Cryptographic
security functions can be summarized by the following concepts.
Core Security Functions

PrivacyProtecting information from unwanted or unauthorized

disclosure. Privacy is provided by encrypting information using the public
key of the intended recipient; thus, it can only be decrypted with the
private key of the intended recipient and no one else can read the
encrypted message.

IdentityThe ability to identify the sender of a message. Because only

the public key corresponding to the senders private key can decrypt the
signature, the identity of the sender can be guaranteed. In a PKI, public
key certificates are typically used for identity. (Public key certificates are
discussed later in this paper).

IntegrityProtecting information from unwanted or unauthorized

modification. The message digest (hash) operation allows a message
recipient to verify that the content has not been altered during
transmission.

Additional Security Functions

The following security functions can be derived from the core privacy,
identity, and integrity functions outlined above:

AuthenticationThe ability to prove a claimed identity. Authentication is

achieved using a digital signature. By verifying the signature on a
message, the recipient can be sure of the identity of the sender.

Access ControlBased on authentication and identity, access control

establishes who can access what. Access controls may be as simple
as encrypting files, or as elaborate as a smart card containing a private
key used with a secure PKI-enabled login.

Non-RepudiationWith the introduction of non-repudiation techniques,

a person cannot deny having committed an action. A persons unique
signature on a contract is proof that he or she has agreed to its terms. If
that person were to deny (repudiate) it later, the contract holder would be
able to point to the signature as evidence. In the digital world, a digital
signature works in much the same waythe secret nature of the private
key means that only one person could have signed the electronic
document containing that electronic signature.

The Value and Importance of the Private Key

Secure storage and protection of private keys is integral to the security of the
Asymmetric Key Cryptography used in a PKI. If someone other than the
actual holder of the key gains access to a private key, the entire PKI security
model breaks down.
For example, if Alice stored her private key in a file on her hard drive and
Charles, a cunning hacker, steals the key, Charles can masquerade as Alice
and neither Bob nor Alice would be aware of the deception. If a private key
fell into the wrong hands, the new holder of the key could easily assume the
identity of the keys real owner during a digital transaction.
While the consequences are trivial in the simple examples presented above,
imagine what could happen if Alice was a purchasing agent with signing
authority for purchase orders up to $1 million and Bob was a vendor:
Charles, Bobs competitor, steals Bobs private key, and sends a false price
quote to Alice signed by Bob, thereby winning the bid and causing Bob
financial ruin. Alternatively, Charles could steal Alices private key and issue
a false $1 million purchase order to himself that would appear to be signed
by Alice.
In both cases, since only Alice and Bob should have had access to their
private keys, there would be some red-faces and explaining to do. Worse yet,
Charles deception may go unnoticed for months, years, or never be
discovered at all.
Therefore, in a PKI environment, particularly one integral to business
processes, financial transactions, or access controls, it is essential that
private keys be guarded with the highest level of security possible.

The Need for Trust

One major problem remainsanyone can create a key that purports to
belong to someone else. Charles could create a key pair and distribute the
public key under the pretense that it belongs to Bob. Charles could then
intercept messages from Alice to Bob, encrypted with Charles deceptive key
pair, decrypt the messages using the private key (that Charles knows), and
then read the message. While this may work for a short time, Alice may
become suspicious if the real Bob fails to keep appointments. More
insidiously, using his fake key pair to pose as Bob, Charles could send
deceitful messages to Alice. Even if Alice were to check the signature, it
would appear as if Bob had sent the message because the key pair would
match. How can Alice trust that the messages actually come from Bob?
The Trusted Third Party
To solve the problem associated with the generation of false key pairs, the
concept of a Trusted Third Party (TTP) is introduced. In simple terms, the
TTP vouches for the identity of an individual, or an entity such as a computer
or Web server. If the example where Charles generated a false key pair to
masquerade as Bob is used, Alice could ask the TTP if the public key
presented by Charles, under the guise of Bob, is really Bobs key.
To verify Bobs identity, the TTP may require evidence, for example, a copy
of a drivers license, a birth certificate, or a photograph, before they will
accept Bobs claim of identity, and vouch for his corresponding public key. In
this case, the TTP responds that the key Alice is questioning actually belongs
to Charles, and Charles schemes would once again be exposed. As long as
the TTPs challenge to prove identity is sufficiently difficult to forge, Alice can
trust the TTP to vouch for the identity of people she communicates with. If
Alice trusts the TTP, she no longer needs to personally verify the identity of
someone she wishes to correspond with before exchanging public keys; the
TTP has already taken appropriate precautions and Alice can work with
confidence.
The presence of a TTP greatly simplifies the process for Alice and Bob, since
neither of them needs to meet in person to verify the others identity. The
TTP, through its diligence, is able to assert the identity of the other parties in
the transaction. To speed up the transaction, the TTP may choose to issue a
document asserting a users identity, similar to a drivers license or passport,
for people to use when they need to identify themselves. The document
indicates that the holder has proven their identity to someone in authority,
and, therefore, is trustworthy. It contains basic information about the person,
such as their name and public key, and information about who issued the
document, so that anyone presented with the document would know where it
came from and whether or not to trust the issuer. While Alice may choose to
trust an identity assertion document presented by Bob from Contoso LTD,
she may not trust one presented by Bob issued by Northwind Traders,
because of Northwind Traders lax security and shoddy business practices.

The Role of the Certificate Authority and Certificates

In the PKI realm, the TTP is known as a Certificate Authority (CA) and the
identity assertions issued by the Certificate Authority are contained in
certificates. Certificates are electronic files that contain information about the
holder of the certificate. For example, a certificate might contain personal
information, such as the name, address, and public key of the certificate
holder, information about the CA, and administrative items such as the type
of certificate and certificate expiration date.
If Alice receives a certificate from Bob, she could (using software) look at the
certificate, ensure that it is valid, verify the identity of the holder, and
determine if she trusts the issuing CA before deciding to trust the assertion
that Bob is, in fact, Bob, and not Charles posing as Bob.
Certificate Authorities and Trust
When a CA issues a certificate, it signs the certificate with its own private key
so that people can be sure of the certificates origins and trust the right CA.
Therefore, the CA must possess a certificate containing its public key to
identify itself and permit the verification of other certificates that it has signed.
Because of this requirement, the CA is in a unique positionit is responsible
for signing its own certificate. In effect, the CAs identity is entirely derived
from the sole fact that it is who it says it is, through a process called selfsigning.
While there is nothing wrong with self-signing in this circumstance, it is
important to note that the CAs private key is very special. Because the CAs
private key signs its own certificate (during the self-signing procedure) and
every other certificate it issues, if the CAs private key fell into the wrong
hands, every certificate ever issued by that CA using that private key could
no longer be trusted.

The Root Key

Because the CAs private key is the anchor to the trustworthiness of all
certificates within a PKI, it is called the root key, owing its name to the fact
that it is the root of trust for all the identities (certificates) in the PKI. A
compromise of the root key means that the network of trust inherent within a
stable PKI collapses. If Charles were to steal the root key of Contoso LTD,
he could issue his own certificates to whomever he chooses. The certificates
issued by Charles would appear to originate from Contoso LTD, and Alice
and Bob could be fooled into trusting false certificates with disastrous
consequences.
Root CAs and Subordinate CAs
A PKI may contain several CAs to distribute the traffic load, or bring the
certificate signing CA closer to the point of issuance. In the latter case, the
CAs are usually arranged in a hierarchy, with a root CA holding the root key
at the top, and one or more subordinate CAs below it. Each subordinate CA
contains a unique private key, but this is not the root key. The subordinate
CAs identity is established with a certificate derived from the subordinate
CAs public/private key, signed by the Root CAs private key. In this way, a
Trust Chain is created, where a certificates authenticity can be traced back
to the root key, even if the issuing CA is a subordinate CA rather than the
Root CA.

When subordinate CAs issue certificates, they sign the certificate with their
own private key. The recipient of the certificate can verify the authenticity of
the subordinate CA by checking the validity of the subordinate CAs
certificate. While not holding the root key, the subordinate CAs private key
must still be protected with the same precautions as the root key. If a
subordinate CAs private key were compromised, the loss of trust within the
PKI would be devastating.
Because of the importance of the root key and the subordinate CAs private
keys, to the operation of a PKI, they should be protected with the best
available physical, technological, and operational security. Hardware Security
Modules (HSMs) address these additional security requirements with secure
hardware to generate, store, and manage sensitive private keys.

The Hardware Security Module

A Hardware Security Module (HSM) is a dedicated hardware device that
works in conjunction with a host CA server to provide a secure hardware
storage location for the CAs root key or subordinate CAs private keys. It is
separately managed and stored outside of the operating system software.

Why an HSM is Important

As certificates have become essential components in electronic business
transactions, the need to maintain the integrity of those certificates, and the
Public Key Infrastructure (PKI) as a whole, has increased. If a CAs root key
is compromised, the credibility of financial transactions, business processes,
and intricate access control systems is adversely affected.
Experience has shown that in order to secure a PKI and maintain the
integrity of the certificates, extraordinary caution should be taken to protect
the root key. For example, the storage of high value root keys should utilize
specialized hardware that is dedicated to preventing theft, tampering, and
access to the secret key material.
A full-scale deployment of a PKI application, such as in a smart card access
control application, secure email, or Secure Sockets Layer (SSL) Web
services used by thousands of employees or customers, may represent a
significant capital investment for an organization. Therefore, the investment
in a reliable, secure Hardware Security Module (HSM) should be considered
a core component due to all of the associated processes, hardware, training,
and operational costs relying on the foundation provided by a PKI.

HSM Functionality
As discussed later in this article, an HSM must maintain the integrity of
private keys in a PKI. An HSM should adhere to one or more recognized
security and operational standards defined by various industry groups, such
as the Federal Information Processing Standard (FIPS), Common Criteria,
etc. An HSM deployment, and supporting operational practices, should also
address the requirements of reputable business processes and security
auditors to provide the highest degree of protection for the CA and its root
keys.
In the deployment of a Microsoft Windows Server Certificate Authority, the
co-deployment of an HSM is highly recommended to protect the CA root
keys and maintain the integrity of the resultant PKI, certificates, and PKIdependent applications.

For additional information on FIPS, visit the National Institute of Standards

and Technologys Computer Security Resource Center Web site at
http://csrc.nist.gov/.

Overview of Luna HSMs

Operational Security

The complete root key life cycle is contained within a Luna HSM secure,
cryptographic hardware module, associated tokens, and validated
storage module. Key material is never available at any time on the host
CAs hard drive, tape backup media, system memory, or smart card.
Note: Key materials contained on a Luna HSM can be permanently
deleted by reinitializing the token, although most audit procedures
specify physical destruction of the token in order to be thorough and
complete. It is also recommended that secure storage and material
access/audit controls be implemented to track all tokens.

The Luna PED provides host-independent authentication.

Built-in secure backup procedures for all physical materials, including

cryptographic hardware tokens and PED keys.

SafeNet incorporates secure manufacturing, shipping, software update,

and verification processes to maintain a trusted source for HSM
hardware.

Rigorous Access Controls

Provides host-independent access controls and authentication with the

incorporation of the Luna PED (PIN Entry Device). The Luna PED is an
HSM-attached keypad that avoids the risk of access codes being
captured from the host through key logging or other techniques.

Three-factor authentication is made available with the mandatory use of

PED keys (key-shaped digital security devices), mandatory PED
personal identification numbers (PINs), and M of N key splitting
(standard feature, installation optional.)

Access controls are stored locally within the cryptographic hardware

token to prevent unauthorized alteration.

Permits split-roles for administrators through role-specific PED keys.

M of N key-splitting prevents unilateral actions. The exploitation of the

HSM when split-keys are used requires collusion between multiple
people, greatly reducing the risk of insider attacks from rogue
administrators.

Features of Luna HSMs

The following is a list of Luna HSM features:

FIPS validation

Hardware-secured key generation, storage, and backup

Hardware-secured digital signing

PKI-authenticated software updates

Host-independent, two-factor authentication

Enforced operational roles

FIPS Validation
Administered by the National Institute of Security and Technology (NIST), the
FIPS standard sets criteria for the physical and operational security of
cryptographic security modules. Differing levels of FIPS validation exist to
accommodate varying levels of security application requirements. FIPS
recognizes four levels (1-4) of validation corresponding to increasing levels of
security in the device. For example, Level 2 provides a higher level of
security than Level 1.
FIPS validation ensures that a device meets the high level of physical
security required when protecting private keys resident on an HSM, including
tamper resistance, physical security, data integrity, and access control
measures. A Threat-Risk Assessment (TRA) from a security consultant can
help you choose the validation level best suited to your application.
Note: More information on FIPS can be found at http://csrc.nist.gov/.

Luna HSMs for root key protection are FIPS Level 3-validated to provide
intrusion resistance and tamper evidence in secure environments.

In addition to an ongoing commitment to producing FIPS-validated

products, SafeNet is incorporating the requirements of emerging
standards, including Common Criteria and FIPS, to ensure its products
meet the future security requirements of its customers.

Hardware-secured key generation

Due to the inherent difficulty in completely securing the Hams host server or
host application from a physical attack or theft, the private key generation
should be performed within the confines of a HSM. If a private key is
generated on the Hams host server, there is a chance that the private key
could be captured or deduced if the host CA system is physically
compromised.

The Luna HSM generates all keys, including private keys, within a
secure cryptographic hardware token.

Luna HSMs also provide additional safeguards during the key generation
procedure by using a secure onboard Random Bit Generator (Annex C
of ANSI 9.17 and X9.82) to create a random key seed.

Hardware-secured Key Storage

To ensure the integrity and security of high value private keys, they are
secured at all times by the HSM. If the private key in plain text or encrypted
file format were stored on the host server's hard drive or in system memory,
then there is the potential for the key to be compromised, copied, deleted, or
otherwise tampered with should an attacker gain physical control of the host
system. Most often, this is attempted through a Trojan horse attack involving
local physical installation of rogue software. Once copied, an attacker can
locate and analyze the plain text private key at leisure. If the private key is
compromised or the only copy the of the key is deleted, generation of a new
private key is required, along with replacement of all certificates signed by
the compromised key, causing significant downtime and replacement costs.

The Luna HSM stores private keys within its FIPS Level 3-validated
secure cryptographic hardware token.

To prevent unauthorized duplication, tampering, or deletion of private

keys, the private key material is never transferred to the host server's
memory or stored on its hard drive.

Hardware-secured Key Backup

It is recommended that backup copies of private keys be made for security
and disaster recovery purposes. However, given the sensitive nature of
private keys, the same precautions that apply to private key storage must
also be applied to the backup copies.
Storing private keys in plain text or encrypted file format on vulnerable
backup media, such as magnetic tape, floppy disks, or optical media, does
not provide adequate security. So that the private key remains under strict
control and is never exposed outside of the HSM, the Luna HSM backs up
key material to secure hardware devices.
Hardware-secured Digital Signing
If cryptographic operations, such as certificate signing, are performed on the
host server, the private key must first be transferred out of the HSM
environment to the host server. Due to the difficulty in completely securing
the host server (which is usually attached to a network), the keys may be
vulnerable if the host server is physically compromised. Therefore, best
practices recommend that all operations requiring the private key be
performed within an HSM.

The Luna HSM performs all cryptographic operations within a secure

hardware token in order to maintain the integrity and security of the
private key when it is used in cryptographic processes.

Luna HSM cryptographic hardware offloads processor-intensive

cryptographic chores from the host server, providing a significant
increase in signing performance, through the use of dedicated
cryptographic hardware processors.

PKI-authenticated HSM Software Updates

To prevent insertion of malicious software code into the HSM, the HSM's
software and firmware must originate from a trusted source and be delivered
via a trusted path to maintain integrity. HSMs use a combination of hardware,
hardware-resident firmware, and software to perform their tasks. During the
manufacture of the HSM, it is necessary to initially program the firmware.
Once programmed, the HSM's firmware and software may be updated to add
functionality. Because firmware has low-level access to the HSM's hardware,
it is essential to prevent unauthorized insertion of software code in order to
maintain the integrity of the HSM.

SafeNet provides rigorous controls over the manufacture, programming,

and maintenance of software code that is placed on Luna HSM secure
cryptographic tokens.

SafeNet hardware components are programmed using an irreversible

anti-fuse process to prevent tampering with the onboard algorithms.
SafeNet then uses a specialized firmware encryption process to load and
verify the firmware on the token. Once programmed, the firmware is
verified on every boot using a CRC (cyclic redundancy code) computed
from the original firmware image.

Hardware design, software development, component assembly, and

shipping are all carefully controlled processes that are thoroughly
monitored for security.

After manufacture, SafeNet continues to protect the integrity of token

firmware during firmware updates. Firmware update images are
encrypted with a randomly-generated key protected by a key derived
from the customer's unique authorization code. This protected key data
is contained within a cryptographic header, signed with the SafeNet
master private key, and appended to the updated image file.

Firmware update will only proceed if the signature on the header is

verified and the image is properly decrypted. The firmware update
process on the token ensures that the updated image is fully and
correctly loaded before it is allowed to execute.

Host-Independent, Two-Factor Authentication

Login and authentication procedures are performed independent of the host
server, using two-factor authentication through a trusted connection path to
the HSM.
To prevent the compromise of private key access controls, SafeNet
recommends that the host server not perform access and authentication
operations pertaining to private key operations. Security exploits to the host,
such as keystroke loggers, may allow access control information to be
captured and exploited. SafeNet provides the Luna PED, a handheld, hostindependent authentication device to address this concern.

Additionally, two-factor authentication is essential in preventing unauthorized

access to the HSM. Two-factor authentication requires two of the following
three types of items to be present for authentication to occur:

Something you knowknowledge of secret data. For example, a

Personal Identification Number (PIN) or password.

Something you havea unique physical item possessed only by

authorized individuals. For example, a security identification badge.

Something you area unique physical characteristic possessed by an

authorized person. The physical characteristic, known as a biometric,
may be a fingerprint, iris scan, or voice print.

By requiring two authentication factors, it becomes considerably more difficult

to gain unauthorized access. For example, while an ID badge may be lost or
stolen, the requirement for a PIN or biometric makes the ID badge useless
on its own. The use of two-factor authentication provides strong
authentication protection for the HSM.
Luna HSM Features

Luna HSMs certified to FIPS level 3 include the Luna PED, a handheld
keypad device. The Luna PED provides independent login and
authentication to the HSM by communicating directly with the
cryptographic token via a dedicated cable connected to the Luna
DOCK's secure data port. This provides a trusted path between the Luna
PED and the Luna cryptographic token during authentication.

The Luna PED provides two-factor authentication by requiring that a

PED key, a key-shaped identification token containing digital
authentication data, and an associated PIN be entered before
authentication can occur and access to the HSM is granted.

Enforced Operational Roles

To prevent unauthorized, unilateral actions by a single person, operational
roles are split so that no one individual has too much operational control.
Access controls are often used to prevent outside access to resources within
an organization, but trusted people within an organization commit a large
percentage of computer crime. Concentration of administrative power into the
hands of a single trusted user makes it easier for that user to damage
systems. It is recommended that operational and administrative roles be
divided among several people in order to prevent unilateral action.

Luna HSM Features

Luna HSM differentiates between five roles that are typically present
during the life of an HSM through the use of different PED keys for
authentication:

The grey PED key is used solely to initialize the token during setup.

The blue PED key is used by the security officer for token
configuration and security management tasks.

The black PED key is held by the administrator for operational user.

The red PED key is used to back up private keys from one Luna
HSM token to another.

The green PED keys are used for secret sharing with M of N access
controls.

No individual holds more than one key, thereby forcing collusion between
trusted parties before a malicious act can be committed.

M of N keys provide additional security by requiring a predefined number

of people (M) out of a group of people (N) be present before the private
key stored on the secure cryptographic token can be accessed, thus
decreasing the risk of collusion between operators even further.

Applying Luna HSM Features and Benefits in

Operational Scenarios
The need for high value root key protection is undeniable. However, using a
secure HSM, and observing best practices during HSM operations and
maintenance, maximizes root key integrity and virtually eliminates the risk of
compromise. The combination of an HSM, coupled with strong operational
practices, negates opportunities for the root key to fall into outside hands,
and thus maintains trust within the Public Key Infrastructure (PKI).
The following scenarios illustrate how the features of Luna HSMs can protect
PKI deployments from a range of security threats.

Scenario 1: A Rogue Administrator

Most security breaches are the act of a trusted employee who has easy
physical and login access to computer resources. These employees may be
motivated to compromise the integrity of the PKI due to job dissatisfaction or
external influence. Internal attackers are very familiar with the systems they
are trying to compromise, often being directly involved with day-to-day
operations, and possibly having user-level access rights that would allow
them to hide or obscure their activities. More often than not, their trusted
status within the organization allows them to be above suspicion until it is too
late.
A rogue administrator can wreak havoc on an unprotected HSM that does
not follow best practices, possibly leading to the collapse of trust within the
PKI. Using personal access privileges, a rogue administrator can steal,
delete, or copy the root key, sign new certificates, or even cause physical
damage to the HSM itself. While certain security breaches are immediately
apparent, others, such as copying, may go undetected, allowing a
compromised HSM to continue to sign certificates.
Luna Solution

Division of Operational RolesLuna HSMs divide the operational

roles among several people within an organization. Through the
mandatory use of the Luna PED and its associated PED keys, the Luna
HSM recognizes five types of users, each with access to specific root
key operations, limiting an individuals ability to compromise the root key.
For example, while an administrative user (possessing a black
administrator PED key) may be able to access the root key and perform
key operations, this person would be unable to delete or copy it because
these operations require the grey initialization PED key and red
group/cloning PED key respectively.

M of N Split-key AuthenticationPrevents unilateral action by

requiring multiple (M) people possessing parts of a shared key (N) to
agree to a course of action. M of N split-key authentication requires
collusion between several people before action can be taken. FIPS Level
3 Luna HSMs includes M of N access through the Luna PED as an
optional level of access control.

FIPS Level 3 ValidationThe intrusion-detection and tamper-evident

housing of a Luna HSM provides a robust defense against direct physical
attack. The secure cryptographic tokens holding the root key can be
further protected with the optional Luna Lock to prevent unauthorized
removal.

Scenario 2: A Compromised Certificate Authority

The very nature of the CA server requires, in most installations, an active
network connection in order to issue certificates. This network, in turn, may
be connected to, or be accessible from, the Internet. Because of the
openness inherent in most network protocols, and the large number of
malicious hackers roaming the Internet, the CA then becomes a potential
target for deliberate or incidental attack from virus, denial of service, and
security exploit attacks. If the root key is stored in plain text or encrypted file
format on the local hard drive or other accessible media, it may be
compromised during an attack through deletion, duplication, or alteration.
Additionally, sniffer programs (a Trojan horse application designed to collect
data) may be placed on a compromised system in an attempt to extract the
root key, in clear text, from the CA system RAM, or a key logger may be
installed to capture login access information. Due to the silent nature of most
electronic crime, these breaches may go undetected for some time, seriously
compromising the integrity of the CA and the PKI around it.
Luna Solution

Secure Hardware Root Key StorageThe root key is protected at all

times within the Luna HSM.

Trusted Path AuthenticationLuna HSMs uses the Luna PED, not the
host CA system, for access control and authentication. The Luna PED is
connected directly to the Luna HSM to create a Trusted Path for
authentication and to eliminate the possibility of PINs or login information
being captured with key loggers resident on the host CA server.

Dedicated Hardware Certificate SigningAll cryptographic processes

that use the root key are performed within the Luna HSM. The root key is
never transmitted to the host CA where it could exist in an unprotected
plain text state in system RAM and become vulnerable to sniffer
programs or buffer overflow exploits.

Scenario 3: Disaster Recovery

The importance of the root key mandates that it be safely backed up to
permit quick recovery from a failure state. In the event of a failure of the host
CA or HSM, it is necessary to ensure that the key is easily restored as
quickly as possible while maintaining the integrity of operational practices. If
the root key, in plain text or encrypted file format, were to be backed up onto
common media, such as a hard drive or magnetic tape, the private key may
be accessible from these insecure media through data extraction techniques.
Additionally, during the deployment of multiple HSMs in a high-availability
cluster, it may be necessary to copy the root key to additional HSMs while
using a secure, trusted path between the devices.
Luna Solution

Secure Hardware Root Key BackupThe Luna HSM backs up the

root key directly from the HSM to a secure Luna hardware backup
device, ensuring that the root key is always maintained in a secure
environment. The backup device can inherit the same access controls as
the HSM itself to prevent unauthorized access to the backup, and since
the backup device is tamper-resistant, the integrity of the backup root
key is protected.

Arrays of Luna HSMs can be established using either backup

devices or network cloningThis permits easy installation of highavailability HSM clusters in data center environments. Access controls
are propagated to the backup device, preventing unauthorized access
and creating a controlled duplication of the root key across multiple
HSMs, as required.

Luna HSMs are independent of the host CA computerA hardware

failure on the host CA does not affect the Luna HSM. Once a
replacement CA system is brought online, it can be quickly registered
with the Luna HSM to continue PKI operation. In the case of a network
shareable Luna HSM, there may be clustered CA servers sharing one or
more Luna HSMs to provide extremely high levels of system availability.

Luna PED and PED Keys

The Luna PED provides direct access and
authentication to a Luna HSM, eliminating
the need to log on through a potentially
unsecure computer. As previously
discussed, the Luna PED uses two-factor
authentication to provide a high degree of
security. Two-factor authentication
requires that two of three elements be
present before authenticating an
individual. To review, these elements may be:

The Luna PED two-factor

authentication device and a
set of PED Keys.

Something you havea unique item that

serves as a security token. An example would
be a key, bank card, or ID badge.

Something you knowknowledge of a secret required for

authentication; for example, a Personal Identification Number (PIN) or
password.

Something you area unique physical identifier that is part of you,

such as a fingerprint or retina scan.

By requiring two authentication factors, it becomes considerably more difficult

to gain unauthorized access. A stolen security badge is useless without the
corresponding PIN. A misplaced PIN will not function without the PIN holders
fingerprint.
The Luna PED provides two-factor authentication through the use of a PED
key and an optional PED PIN. Additionally, a third factor may be added
through the use of M of N key splitting.

PED Keys
A PED key is a key-shaped security device that works in conjunction with the
Luna PED. The PED key serves three distinct roles in maintaining the
security of the Luna HSM:

Physical SecurityThe key-shaped design of the PED key is required

to operate the key slot on the Luna PED during authentication.

Authentication TokenThe PED key functions as a unique physical

authentication token (something you have) during authentication. Each
PED key is imprinted with a unique digital identifier specific to the Luna
HSM during the initialization process.

Division of Operational RolesThe PED keys allow for division of

operational roles. Each PED key corresponds to a different role in the
administration hierarchy of the Luna HSM, ensuring that no single
individual has too much operational control.

What PED Keys Do

Color-coded PED keys correspond to a specific operational role, as shown in
the figure below. While some PED keys are required for the operation of the
Luna HSM, others are only needed to enable extra security features.

Grey (Initialization) KeyMandatory. Generally used only once, this

key is needed to initialize the Luna HSM.

Blue (Security Officer) KeyMandatory. This key is possessed by the

security officer (SO) whose role is defined by your corporate security
policy.

Red (Group/Domain/Cloning) KeyMandatory. This key sets the

membership of a token to a defined domain, or permits the cloning of
one tokens contents to another. A red key is mandatory, but a shared
domain is not.

Black (User) KeyMandatory. Defines users who have access to

administrative functions of the token.

Green (M of N) KeysOptional. These keys are used to set M of N

access policy. M of N keys require that a defined number of shared
secret keys (N) be present (M) before an administrative action can be
performed, preventing unilateral actions.

PED keys are an important part of the operational procedures of a Luna HSM
and should be treated with care. The keys should be clearly labeled and
stored in a safe, secure location at all times. Because the round handle of the
PED key does not contain electronic components, it can be labeled or
engraved for identification.

SafeNet Overview
SafeNet (NASDAQ: SFNT) is a global leader in information security.
Founded more than 20 years ago, the company provides complete security
utilizing its encryption technologies to protect communications, intellectual
property, and digital identities, and offers a full spectrum of products
including hardware, software, and chips. ARM, Bank of America, Cisco
Systems, the Departments of Defense, and Homeland Security, Microsoft,
Samsung, Texas Instruments, the U.S. Internal Revenue Service, and scores
of other customers entrust their security needs to SafeNet. For more
information, visit www.safenet-inc.com.

w w w . s a f e n e t - i n c . c o m
Corporate Headquarters: 4690 Millennium Drive, Belcamp, Maryland 21017 USA
Tel: +1 410.931.7500 or 800.533.3958 email: info@safenet-inc.com

Phone USA and Canada (800) 533-3958

Phone Other Countries (410) 931-7500
Fax (410) 931-7524
Email
info@safenet-inc.com
Web site www.safenet-inc.com
2004 SafeNet, Inc. This document contains information that is proprietary to SafeNet, Inc.
No part of this document may be reproduced in any form without prior written approval by
SafeNet. SafeNet shall have no liability for errors, omissions or inadequacies in the information
contained herein or for interpretation thereof. The opinions expressed herein are subject to
change without notice.

Australia +61 3 9882 8322

Brazil +55 11 6121 6455
Canada 613.723.5077
China +86 10 8266 3936
Finland +358 20 500 7800
France +33 1 41 43 29 00
Germany +49 18 03 72 46 26 9
Hong Kong +852 3157 7111
India +91 11 26917538
Japan(Tokyo) +81 3 5719 2731
Korea +82 31 705 8212
Mexico +52 55 5575 1441
Netherlands +31 73 658 1900
Singapore +65 6297 6196
Taiwan +886 2 27353736
UK +44 1276 608 000
U.S. (Massachusetts) +1 978.539.4800
U.S. (New Jersey) +1 201.333.3400
U.S. (Virginia) +1 703.279.4500
U.S. (Irvine, California) +1 949.450.7300
U.S. (Santa Clara, California)
+1 408.855.6000
U.S. (Torrance, California)
+1 310.533.8100
Distributors and resellers
located worldwide.