Introduction to PKI & SafeNet                                     Luna Hardware Security Modules                          ...
Public Key Infrastructure BasicsOnce the realm of superpower spy organizations, the Asymmetric Key Encryption technology a...
Signing Proves IdentityIf Alice wants Bob to know for certain that she wrote the message, she can choose to sign(encrypt) ...
Additional Security FunctionsThe following security functions can be derived from the core privacy, identity, and integrit...
the trusted third PartyTo solve the problem associated with the generation of false key pairs, the concept of a TrustedThi...
the root KeyBecause the CA’s private key is the anchor to the trustworthiness of all certificates within a PKI,it is calle...
hSM FunctionalityAs discussed later in this article, an HSM must maintain the integrity of private keys in a PKI. AnHSM sh...
Features of Luna hSMsThe following is a list of Luna HSM features:  •	 FIPS validation  •	 Hardware-secured key generation...
private key at leisure. If the private key is compromised or the only copy the of the key is deleted,generation of a new p...
•	 After manufacture, SafeNet continues to protect the integrity of token firmware during     firmware updates. Firmware u...
Concentration of administrative power into the hands of a single “trusted” user makes it easierfor that user to damage sys...
example, while an administrative user (possessing a black administrator PED key) may be    able to access the root key and...
Luna Solution                                           •	 Secure hardware root Key Backup—The Luna HSM backs up the root ...
what PeD Keys DoColor-coded PED keys correspond to a specific operational role, as shown in the figure below.While some PE...
Upcoming SlideShare
Loading in …5

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


Published on

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

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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

  1. 1. Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows whItePAPer IntroductionOverview To aid a successful and secure Public Key Infrastructure (PKI) implementation, this articleCertificate Services in Microsoft® examines the essential concepts, technology, components, and operations associated withWindows® Server products deploying a Microsoft PKI with root key protection performed by a SafeNet Luna Hardwareprovide an integrated Public Security Module (HSM).Key Infrastructure (PKI) for useby a wide range of Windows PKI—A Critical Building Block in Computer SecuritySolutionsapplications. This paper examines In a world increasingly reliant on computers, computer networks, and digital information tohow the addition of a SafeNet conduct business, devising ways to ensure the security of electronic business transactionsLuna 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 collectionsecurity in a Windows Server PKI of 1s and 0s in computer files. Because of their intangible nature, details of these electronicdeployment. 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. 2. Public Key Infrastructure BasicsOnce the realm of superpower spy organizations, the Asymmetric Key Encryption technology atthe heart of a PKI is now commonly used to enforce corporate, industry, and personal security inthe electronic age.PKI and Asymmetric Key encryption—A heritage of trustAsymmetric Key Encryption technology, and the Public Key Infrastructure (PKI) umbrella thatsurrounds it, was born out of academic research and Cold War necessity in the late 1960s toearly 1970s. This intelligence has evolved into business tools that solve the security problemsinherent in today’s digital transactions. Along with the phenomenal growth in computing powerand network connectivity, sophisticated, strong encryption technology is now attainable with astandard 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 securingconfidential records through encryption.However, advanced cryptography and personal computing horsepower are only the tip of theiceberg when deploying a PKI in a business environment. The implementer of a PKI must giveequal, if not greater, significance to design, integration, physical security, and operationalpractices 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 whohave never met to agree on a cryptographic key that allows them to exchange a suitable set ofencryption keys for their It worksWho exactly are Alice, Bob, and Charles? Just as Dick, Spot, and Jane were invented to teachreading, cryptographers created Alice, Bob, and Charles to illustrate encryption technology andits importance in the business world.Alice and Bob represent individuals who wish to secure their communications, while Charlesrepresents an outside party who is attempting to intercept private messages or deceive theother 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 anencryption key, that can be freely shared and distributed; the other is a private key, also called adecryption 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 messagewith Bob’s public key (which is freely available) and sends it to Bob. When Bob receives themessage, he uses his secret private key to decrypt the message. If the message were interceptedby Charles, who hopes to snoop into Alice and Bob’s business, he would be unable to decipherit. Although Charles can easily look up Bob’s public key, the message can be decoded only withBob’s secret private key. Provided that Bob’s encryption key is large enough to prevent brute forcedecryption attacks, the privacy of the message can be guaranteed because only the intendedrecipient 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, Charlescould 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. 3. 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’spublic key. Imagine a digital envelope with Bob’s name on it wrapped around the signed messagefrom Alice. When Bob receives the message, he can remove the “envelope” by decrypting themessage contents with his private key; he can then decrypt the digital signature on the signedmessage inside the “envelope” using Alice’s freely available public key to verify Alice’s identity asthe sender.Because a signature can be decrypted by anyone with access to the signer’s public key, it offersno 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, Bobcan 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 aperson’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? Anothermathematical technique, called a hash or digest, ensures that Charles’ deception can be easilyspotted.A hash is a simple procedure that is highly effective in thwarting Charles’ efforts. A hash is amathematical digest of the contents of the message, creating a number that is unique to thatmessage. A simple hash might consist of assigning a number between 1 and 26 to each letter inthe 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 herprivate key, and includes the signed hash with the body of the message she encrypted with Bob’spublic key. Once a hash is generated and included with the message, any changes or additions tothe originally hashed message will be evident to Bob.When Bob receives the message, he decrypts it, verifies the signature on the hash, and appliesthe same hashing function to the decrypted message. If the hash value that Bob receives fromhis decrypted message matches the hash signed by Alice, the message has not been tamperedwith. If Charles had modified the message in transit, the hash values would be different and thedeception 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 securityin today’s Internet communications. Cryptographic security functions can be summarized by thefollowing 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. 4. Additional Security FunctionsThe following security functions can be derived from the core privacy, identity, and integrityfunctions 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 KeyCryptography used in a PKI. If someone other than the actual holder of the key gains access to aprivate 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 cunninghacker, steals the key, Charles can masquerade as Alice and neither Bob nor Alice would beaware of the deception. If a private key fell into the wrong hands, the new holder of the key couldeasily 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 couldhappen if Alice was a purchasing agent with signing authority for purchase orders up to $1million and Bob was a vendor: Charles, Bob’s competitor, steals Bob’s private key, and sends afalse 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 tohimself 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 wouldbe some red-faces and explaining to do. Worse yet, Charles’ deception may go unnoticed formonths, years, or never be discovered at all.Therefore, in a PKI environment, particularly one integral to business processes, financialtransactions, or access controls, it is essential that private keys be guarded with the highestlevel 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 belongsto 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 thenread the message. While this may work for a short time, Alice may become suspicious if the realBob fails to keep appointments. More insidiously, using his fake key pair to pose as Bob, Charlescould send deceitful messages to Alice. Even if Alice were to check the signature, it would appearas if Bob had sent the message because the key pair would match. How can Alice trust that themessages actually come from Bob?Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 4
  5. 5. the trusted third PartyTo solve the problem associated with the generation of false key pairs, the concept of a TrustedThird 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 falsekey pair to masquerade as Bob is used, Alice could ask the TTP if the public key presented byCharles, under the guise of Bob, is really Bob’s key. To verify Bob’s identity, the TTP may requireevidence, for example, a copy of a driver’s license, a birth certificate, or a photograph, before theywill accept Bob’s claim of identity, and vouch for his corresponding public key. In this case, theTTP responds that the key Alice is questioning actually belongs to Charles, and Charles’ schemeswould once again be exposed. As long as the TTP’s challenge to prove identity is sufficientlydifficult to forge, Alice can trust the TTP to vouch for the identity of people she communicateswith. If Alice trusts the TTP, she no longer needs to personally verify the identity of someone shewishes to correspond with before exchanging public keys; the TTP has already taken appropriateprecautions and Alice can work with confidence.The presence of a TTP greatly simplifies the process for Alice and Bob, sinceneither of themneeds to meet in person to verify the other’s identity. TheTTP, through its diligence, is ableto assert the identity of the other parties inthe transaction. To speed up the transaction, theTTP may choose to issue adocument asserting a user’s identity, similar to a driver’s license orpassport,for people to use when they need to identify themselves. The documentindicates thatthe holder has proven their identity to someone in authority,and, therefore, is trustworthy. Itcontains basic information about the person,such as their name and public key, and informationabout who issued thedocument, so that anyone presented with the document would know whereitcame from and whether or not to trust the issuer. While Alice may choose totrust an identityassertion document presented by Bob from Contoso LTD,she may not trust one presented by Bobissued by Northwind Traders,because of Northwind Traders’ lax security and shoddy businesspractices.the role of the Certificate Authority and CertificatesIn the PKI realm, the TTP is known as a Certificate Authority (CA) and the identity assertionsissued by the Certificate Authority are contained in certificates. Certificates are electronic filesthat contain information about the holder of the certificate. For example, a certificate mightcontain personal information, such as the name, address, and public key of the certificateholder, information about the CA, and administrative items such as the type of certificate andcertificate expiration date.If Alice receives a certificate from Bob, she could (using software) look at the certificate, ensurethat it is valid, verify the identity of the holder, and determine if she trusts the issuing CA beforedeciding 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 peoplecan be sure of the certificate’s origins and trust the right CA. Therefore, the CA must possessa certificate containing its public key to identify itself and permit the verification of othercertificates that it has signed. Because of this requirement, the CA is in a unique position—it isresponsible for signing its own certificate. In effect, the CA’s identity is entirely derived from thesole 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 thatthe CA’s private key is very special. Because the CA’s private key signs its own certificate (duringthe self-signing procedure) and every other certificate it issues, if the CA’s private key fell intothe wrong hands, every certificate ever issued by that CA using that private key couldno longer be trusted.Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 5
  6. 6. 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 inherentwithin a stable PKI collapses. If Charles were to steal the root key of Contoso LTD, he could issuehis own certificates to whomever he chooses. The certificates issued by Charles would appearto originate from Contoso LTD, and Alice and Bob could be fooled into trusting false certificateswith disastrous consequences.root CAs and Subordinate CAsA PKI may contain several CAs to distribute the traffic load, or bring thecertificate signing CAcloser 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. Eachsubordinate CA contains a unique private key, but this is not the root key. The subordinateCA’s identity is established with a certificate derived from the subordinate CA’s public/privatekey, signed by the Root CA’s private key. In this way, a Trust Chain is created, where a certificate’sauthenticity can be traced back to the root key, even if the issuing CA is a subordinate CA ratherthan 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 thevalidity of the subordinate CA’s certificate. While not holding the root key, the subordinate CA’sprivate key must still be protected with the same precautions as the root key. If a subordinateCA’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 theoperation of a PKI, they should be protected with the best available physical, technological,and operational security. Hardware Security Modules (HSMs) address these additional securityrequirements 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 conjunctionwith a host CA server to provide a secure hardware storage location for the CA’s root key orsubordinate CAs’ private keys. It is separately managed and stored outside of the operatingsystem software.why an hSM is ImportantAs certificates have become essential components in electronic business transactions, theneed to maintain the integrity of those certificates, and the Public Key Infrastructure (PKI) as awhole, 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 ofhigh 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 orcustomers, may represent a significant capital investment for an organization. Therefore, theinvestment in a reliable, secure Hardware Security Module (HSM) should be considered a corecomponent due to all of the associated processes, hardware, training, and operational costsrelying on the foundation provided by a PKI.Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 6
  7. 7. hSM FunctionalityAs discussed later in this article, an HSM must maintain the integrity of private keys in a PKI. AnHSM should adhere to one or more recognized security and operational standards defined byvarious industry groups, such as the Federal Information Processing Standard (FIPS), CommonCriteria, etc. An HSM deployment, and supporting operational practices, should also addressthe requirements of reputable business processes and security auditors to provide the highestdegree of protection for the CA and its root keys.In the deployment of a Microsoft Windows Server Certificate Authority, the co-deployment ofan HSM is highly recommended to protect the CA root keys and maintain the integrity of theresultant PKI, certificates, and PKIdependent applicationsFor additional information on FIPS, visit the National Institute of Standards and technology’sComputer Security resource Center web site at of Luna hSMsOperational 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 thetoken, although most audit procedures specify physical destruction of the token in order to bethorough and complete. It is also recommended that secure storage and material access/auditcontrols 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 Controlsrigorous 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 administratorsIntroduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 7
  8. 8. 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 rolesFIPS ValidationAdministered by the National Institute of Security and Technology (NIST), the FIPS standardsets criteria for the physical and operational security of cryptographic security modules.Differing levels of FIPS validation exist to accommodate varying levels of security applicationrequirements. FIPS recognizes four levels (1-4) of validation corresponding to increasing levels ofsecurity 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 whenprotecting private keys resident on an HSM, including tamper resistance, physical security,data integrity, and access control measures. A Threat-Risk Assessment (TRA) from a securityconsultant can help you choose the validation level best suited to your application.Note: More information on FIPS can be found at • 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 applicationfrom a physical attack or theft, the private key generation should be performed within theconfines of a HSM. If a private key is generated on the Ham’s host server, there is a chance thatthe 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 bythe HSM. If the private key in plain text or encrypted file format were stored on the host server’shard 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 thehost system. Most often, this is attempted through a Trojan horse attack involving local physicalinstallation of rogue software. Once copied, an attacker can locate and analyze the plain textIntroduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 8
  9. 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 bythe 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 recoverypurposes. However, given the sensitive nature of private keys, the same precautions that apply toprivate 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 asmagnetic tape, floppy disks, or optical media, does not provide adequate security. So that theprivate key remains under strict control and is never exposed outside of the HSM, the Luna HSMbacks up key material to secure hardware devices.hardware-secured Digital SigningIf cryptographic operations, such as certificate signing, are performed on the host server, theprivate key must first be transferred out of the HSM environment to the host server. Due to thedifficulty in completely securing the host server (which is usually attached to a network), thekeys may be vulnerable if the host server is physically compromised. Therefore, best practicesrecommend 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 firmwaremust 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 performtheir 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 preventunauthorized 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. 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, 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 hostserver not perform access and authentication operations pertaining to private key operations.Security exploits to the host, such as keystroke loggers, may allow access control informationto be captured and exploited. SafeNet provides the Luna PED, a handheld, hostindependentauthentication device to address this concern.Additionally, two-factor authentication is essential in preventing unauthorized access to theHSM. Two-factor authentication requires two of the following three types of items to be presentfor 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 gainunauthorized access. For example, while an ID badge may be lost or stolen, the requirement fora PIN or biometric makes the ID badge useless on its own. The use of two-factor authenticationprovides 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 rolesTo prevent unauthorized, unilateral actions by a single person, operational roles are split so thatno 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. 11. Concentration of administrative power into the hands of a single “trusted” user makes it easierfor that user to damage systems. It is recommended that operational and administrative roles bedivided 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 HSMthrough 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, andobserving best practices during HSM operations and maintenance, maximizes root key integrityand virtually eliminates the risk of compromise. The combination of an HSM, coupled with strongoperational practices, negates opportunities for the root key to fall into outside hands, and thusmaintains trust within the Public Key Infrastructure (PKI).The following scenarios illustrate how the features of Luna HSMs can protect PKI deploymentsfrom a range of security threats.Scenario 1: A rogue AdministratorMost security breaches are the act of a trusted employee who has easy physical and loginaccess to computer resources. These employees may be motivated to compromise the integrityof the PKI due to job dissatisfaction or external influence. Internal attackers are very familiarwith the systems they are trying to compromise, often being directly involved with day-to-dayoperations, and possibly having user-level access rights that would allow them to hide orobscure their activities. More often than not, their trusted status within the organization allowsthem to be above suspicion until it is too late.A rogue administrator can wreak havoc on an unprotected HSM that does not follow bestpractices, possibly leading to the collapse of trust within the PKI. Using personal accessprivileges, a rogue administrator can steal, delete, or copy the root key, sign new certificates, oreven cause physical damage to the HSM itself. While certain security breaches are immediatelyapparent, others, such as copying, may go undetected, allowing a compromised HSM to continueto 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. ForIntroduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 11
  12. 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 AuthorityThe very nature of the CA server requires, in most installations, an active network connection inorder to issue certificates. This network, in turn, may be connected to, or be accessible from, theInternet. Because of the openness inherent in most network protocols, and the large number ofmalicious hackers roaming the Internet, the CA then becomes a potential target for deliberateor incidental attack from virus, denial of service, and security exploit attacks. If the root key isstored in plain text or encrypted file format on the local hard drive or other accessible media, itmay 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 aompromised 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 ofmost electronic crime, these breaches may go undetected for some time, seriously compromisingthe 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 recoveryThe importance of the root key mandates that it be safely backed up to permit quick recoveryfrom a failure state. In the event of a failure of the host CA or HSM, it is necessary to ensure thatthe key is easily restored as quickly as possible while maintaining the integrity of operationalpractices. If the root key, in plain text or encrypted file format, were to be backed up ontocommon media, such as a hard drive or magnetic tape, the private key may be accessible fromthese insecure media through data extraction techniques.Additionally, during the deployment of multiple HSMs in a high-availability cluster, it may benecessary to copy the root key to additional HSMs while using a secure, trusted path betweenthe devices.Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 12
  13. 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. 14. 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 toenable 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 betreated with care. The keys should be clearly labeled and stored in a safe, secure location at alltimes. Because the round handle of the PED key does not contain electronic components, it canbe 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 authenticateAbout SafeNetFounded in 1983, SafeNet is a global leader in information security. SafeNet protects itscustomers’ most valuable assets, including identities, transactions, communications, dataand software licensing, throughout the data lifecycle. More than 25,000 customers acrossboth commercial enterprises and government agencies and in over 100 countries trust theirinformation security needs to SafeNet.Contact Us: For all office locations and contact information, please visit www.safenet-inc.comFollow Us:©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.10Introduction to PKI & SafeNet Luna Hardware Security Modules with Microsoft Windows White Paper 14