Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows

Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 1

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

PKI—A Critical Building Block in Computer SecuritySolutionsIn 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 tra sactions 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 solution—asymmetric key encryption and digital signatures within a PKI security framework.

Introduction to PKI & SafeNet Luna Hardware Security Moduleswith Microsoft WindowswhItePAPer

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


Public Key Infrastructure BasicsOnce 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 trustAsymmetric 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 encryptionWithout 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 worksWho 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 encryptionPrivacy 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.


Signing Proves IdentityIf 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 IntegrityWhat 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 FunctionsThe 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 FunctionsPrivacy• —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.


Additional Security FunctionsThe 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 KeySecure 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 trustOne 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?


the trusted third PartyTo 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 CertificatesIn 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 trustWhen 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.


the root KeyBecause 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 CAsA 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 ModuleA 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 ImportantAs 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.


hSM FunctionalityAs 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 SecurityThe 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 ControlsProvides 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 hSMsThe 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 ValidationAdministered 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 generatioDue 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 StorageTo 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-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 BackupIt 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 UpdatesTo 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 AuthenticationLogin 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 FeaturesLuna 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 rolesTo 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 FeaturesLuna 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 ScenariosThe 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 AdministratorMost 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 SolutionDivision 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


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 AuthorityThe 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 SolutionSecure 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 recoveryThe 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 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 KeysThe 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.

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

The Luna PED two-factor authentication device and a set of PED Keys.


Contact Us: For all office locations and contact information, please visit www.safenet-inc.comFollow Us: www.safenet-inc.com/connected

©2010 SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners. WP (EN)-11.17.10

what PeD Keys DoColor-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

InitializationToken Initialization

(one time only)Vault

Security Officer

Token administration Set token policy Select token initialization parameters Create Users

CSO

CIO

Domain Cloning Token Backup

Set cloning policy

Create/transfer cloning

domains

Token backup

Domian

Administator

WAN

Administator

UserKey generation

Signing

Decryption

System

Administrator

M of N

Shared secret M of N

authentication

M keys of N key set required

to authenticate

IT Staff

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.

Init

ializ

atio

n

Adm

inis

trat

or

Dai

ly O

pera

tion

Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows

Technology

cryptographic key

bobs encryption key

key pairthat

adecryption key

anencryption key

messagewith bobs public

pki security framework

root key protection