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).

1. Introduction to PKI & SafeNet
Luna Hardware Security Modules
with Microsoft Windows
whItePAPer
Introduction
Overview To aid a successful and secure Public Key Infrastructure (PKI) implementation, this article
Certificate Services in Microsoft® examines the essential concepts, technology, components, and operations associated with
Windows® Server products deploying a Microsoft PKI with root key protection performed by a SafeNet Luna Hardware
provide an integrated Public Security Module (HSM).
Key Infrastructure (PKI) for use
by a wide range of Windows PKI—A Critical Building Block in Computer SecuritySolutions
applications. This paper examines In a world increasingly reliant on computers, computer networks, and digital information to
how the addition of a SafeNet conduct business, devising ways to ensure the security of electronic business transactions
Luna Hardware Security Module has taken on acute importance. Unlike traditional business transactions, with face-to-face
(HSM) provides a higher level of meetings and notarized paper contracts, electronic tra sactions exist merely as a collection
security in a Windows Server PKI of 1s and 0s in computer files. Because of their intangible nature, details of these electronic
deployment. 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 solution—asymmetric key encryption
and digital signatures within a PKI security framework.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 1

2. 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 encryption—A 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 today’s 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,
symmetric 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 Bob’s 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 Bob’s business, he would be unable to decipher
it. Although Charles can easily look up Bob’s public key, the message can be decoded only with
Bob’s secret private key. Provided that Bob’s 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 Alice’s email is secure, how does Bob know if Alice was the actual sender?
Because Bob’s 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.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 2

3. 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 Bob’s
public key. Imagine a digital envelope with Bob’s 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 Alice’s freely available public key to verify Alice’s identity as
the sender.
Because a signature can be decrypted by anyone with access to the signer’s public key, it offers
no privacy. However, a signed message does guarantee that the sender is who they say they are.
Because only Alice’s public key can decrypt the signature created using Alice’s 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
person’s 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 Bob’s
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 today’s Internet communications. Cryptographic security functions can be summarized by the
following concepts.
Core Security Functions
• Privacy—Protecting 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.
• Identity—The ability to identify the sender of a message. Because only the public key
corresponding to the sender’s 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).
• Integrity—Protecting 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.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 3

4. Additional Security Functions
The following security functions can be derived from the core privacy, identity, and integrity
functions outlined above:
• Authentication—The 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 Control—Based 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-repudiation—With the introduction of non-repudiation techniques, a person cannot
deny having committed an action. A person’s 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 way—the 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 key’s 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, Bob’s competitor, steals Bob’s 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 Alice’s 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 remains—anyone 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?
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 4

5. 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 Bob’s key. To verify Bob’s identity, the TTP may require
evidence, for example, a copy of a driver’s license, a birth certificate, or a photograph, before they
will accept Bob’s 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 TTP’s 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, sinceneither of them
needs to meet in person to verify the other’s identity. TheTTP, through its diligence, is able
to assert the identity of the other parties inthe transaction. To speed up the transaction, the
TTP may choose to issue adocument asserting a user’s identity, similar to a driver’s license or
passport,for people to use when they need to identify themselves. The documentindicates 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 thedocument, so that anyone presented with the document would know where
itcame from and whether or not to trust the issuer. While Alice may choose totrust 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 certificate’s 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 position—it is
responsible for signing its own certificate. In effect, the CA’s 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 CA’s private key is very special. Because the CA’s private key signs its own certificate (during
the self-signing procedure) and every other certificate it issues, if the CA’s private key fell into
the wrong hands, every certificate ever issued by that CA using that private key could
no longer be trusted.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 5

6. the root Key
Because the CA’s 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 thecertificate 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
CA’s identity is established with a certificate derived from the subordinate CA’s public/private
key, signed by the Root CA’s private key. In this way, a Trust Chain is created, where a certificate’s
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 CA’s certificate. While not holding the root key, the subordinate CA’s
private key must still be protected with the same precautions as the root key. If a subordinate
CA’s 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 CA’s 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 CA’s 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.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 6

7. 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 technology’s
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 CA’s 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
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
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 7

8. 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 generatio
Due to the inherent difficulty in completely securing the Ham’s 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 Ham’s 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
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 8

9. 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-validatedsecure 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.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 9

10. • 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 know—knowledge of secret data. For example, a Personal Identification
Number (PIN) or password.
• Something you have—a unique physical item possessed only by authorized individuals. For
example, a security identification badge.
• Something you are—a 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.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 10

11. 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 roles—Luna 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 individual’s ability to compromise the root key. For
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 11

12. 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 Authentication—Prevents 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 Validation—The 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
ompromised 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 Storage—The root key is protected at all times within the Luna
HSM.
• trusted Path Authentication—Luna 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 Signing—All 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.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 12

13. Luna Solution
• Secure hardware root Key Backup—The 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 cloning—
This 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 computer—A 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:
• Something you have—a unique item that serves as a security token. An example would be a
key, bank card, or ID badge.
• Something you know—knowledge of a secret required for authentication; for example, a
Personal Identification Number (PIN) or password.
• Something you are—a unique physical identifier that is part of you, such as a fingerprint or
retina scan.
The Luna PED two-factor authentication By requiring two authentication factors, it becomes considerably more difficult to gain
device and a set of PED Keys. unauthorized access. A stolen security badge is useless without the corresponding PIN. A
misplaced PIN will not function without the PIN holder’s 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 Security—The key-shaped design of the PED key is required to operate the key slot
on the Luna PED during authentication.
• Authentication token—The 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 roles—The 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.
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 13

14. 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) Key—Mandatory. Generally used only once, this key is needed to
initialize the Luna HSM.
• Blue (Security Officer) Key—Mandatory. This key is possessed by the security officer (SO)
whose role is defined by your corporate security policy.
• red (Group/Domain/Cloning) Key—Mandatory. This key sets the membership of a token
to a defined domain, or permits the cloning of one token’s contents to another. A red key is
mandatory, but a shared domain is not.
• Black (User) Key—Mandatory. Defines users who have access to administrative functions of
the token.
• Green (M of N) Keys—Optional. 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.
Lifecycle PED Key Operational Role Function Custodian
Token Initialization
Initialization Vault
(one time only)
Token administration
Set token policy
Initialization
CSO
Security Officer Select token initialization
Administrator
parameters CIO
Create Users
Set cloning policy Domian
Domain Cloning Create/transfer cloning Administator
Token Backup domains WAN
Token backup Administator
Key generation
System
User
Daily Operation
Signing
Administrator
Decryption
Shared secret M of N
authentication
M of N IT Staff
M keys of N key set required
to authenticate
About SafeNet
Founded in 1983, SafeNet is a global leader in information security. SafeNet protects its
customers’ most valuable assets, including identities, transactions, communications, data
and software licensing, throughout the data lifecycle. More than 25,000 customers across
both commercial enterprises and government agencies and in over 100 countries trust their
information security needs to SafeNet.
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)-11.17.10
Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 14