Wp Pki IntroPKILuna

8/10/2019 Wp Pki IntroPKILuna

http://slidepdf.com/reader/full/wp-pki-intropkiluna 1/19

Introduction to PKI & SafeNet Luna

Hardware Security Moduleswith Microsoft Windows

OverviewCertificate Services in Microsoft® Windows® Server products provide anintegrated Public Key Infrastructure (PKI) for use by a wide range ofWindows applications. This paper examines how the addition of a SafeNetLuna Hardware Security Module (HSM) provides a higher level of security ina Windows Server PKI deployment.

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 withroot key protection performed by a SafeNet Luna Hardware Security Module(HSM).

PKI—A Critical Building Block in Computer SecuritySolutions

In a world increasingly reliant on computers, computer networks, and digitalinformation to conduct business, devising ways to ensure the security ofelectronic business transactions has taken on acute importance. Unliketraditional business transactions, with face-to-face meetings and notarizedpaper contracts, electronic transactions exist merely as a collection of 1s and0s in computer files. Because of their intangible nature, details of these

electronic transactions can be stolen, misrepresented, manipulated, orrefuted by the people involved more readily than in the past.

The importance of a flexible, robust security system becomes apparent whenconsidering the problems with securing access controls and permissionmanagement for an ever-growing network of computers, as well as concernsover privacy and security on corporate networks and the Internet.



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

• Identity

• Integrity

• Privacy

• Authentication

• Access control

• Non-repudiation

Fortunately, cryptographic technology offers a proven solution—asymmetrickey encryption and digital signatures within a PKI security framework.

Public Key Infrastructure BasicsOnce the realm of superpower spy organizations, the Asymmetric KeyEncryption technology at the heart of a PKI is now commonly used to enforce

corporate, industry, and personal security in the electronic age.

PKI and Asymmetric Key Encryption—A Heritage of Trust

Asymmetric Key Encryption technology, and the Public Key Infrastructure(PKI) umbrella that surrounds it, was born out of academic research andCold War necessity in the late 1960s to early 1970s. This intelligence hasevolved into business tools that solve the security problems inherent intoday’s digital transactions. Along with the phenomenal growth in computingpower and network connectivity, sophisticated, strong encryption technologyis now attainable with a standard desktop computer.

PKI now spans the globe via computers linked to the Internet, helping usersshop 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 areonly 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 todesign, integration, physical security, and operational practices to ensure thatthe PKI stays secure as intended.

Asymmetric Key Encryption

Without delving into the complex mathematics that make moderncryptography possible, Asymmetric Key Encryption can be described as atechnique that allows two or more people who have never met to agree on acryptographic key that allows them to exchange a suitable set of encryption

keys for their message.



How It Works

Who exactly are Alice, Bob, and Charles? Just as Dick, Spot, and Jane wereinvented to teach reading, cryptographers created Alice, Bob, and Charles toillustrate 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 isattempting 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 publickey, 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 secretand known only to the person who holds it.

The Functions of Asymmetric Key Encryption

Privacy through Encryption

When Alice wishes to send Bob a message, she encrypts the message withBob’s public key (which is freely available) and sends it to Bob. When Bobreceives the message, he uses his secret private key to decrypt themessage. If the message were intercepted by Charles, who hopes to snoopinto Alice and Bob’s business, he would be unable to decipher it. AlthoughCharles can easily look up Bob’s public key, the message can be decodedonly with Bob’s secret private key. Provided that Bob’s encryption key islarge enough to prevent brute force decryption attacks, the privacy of themessage can be guaranteed because only the intended recipient candecipher it.

However, although Alice’s email is secure, how does Bob know if Alice wasthe actual sender? Because Bob’s freely available public key is all that isrequired to encrypt the message, Charles could easily compose a messageto Bob and make it appear to have originated from Alice. Asymmetric Key

Encryption offers a solution for this as well, called signing.

Signing Proves Identity

If Alice wants Bob to know for certain that she wrote the message, she canchoose 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 withBob’s name on it wrapped around the signed message from Alice. When Bobreceives the message, he can remove the “envelope” by decrypting themessage contents with his private key; he can then decrypt the digitalsignature on the signed message inside the “envelope” using Alice’s freelyavailable public key to verify Alice’s identity as the sender.

Because a signature can be decrypted by anyone with access to the signer’spublic 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 candecrypt the signature created using Alice’s private key, Bob can be assuredthat Alice wrote the message. If Charles attempts to forge an email from

Alice, Bob can easily discover it because the signatures will not match. Withsigning, you can verify a person’s identity in a transaction, provided that onlythey know their private key.



Hashing for Message Integrity

What if Charles were to intercept and attempt to alter the email that Alicesent 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 mightconsist of assigning a number between 1 and 26 to each letter in thealphabet 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 thebody of the message she encrypted with Bob’s public key. Once a hash isgenerated and included with the message, any changes or additions to theoriginally hashed message will be evident to Bob.

When Bob receives the message, he decrypts it, verifies the signature on thehash, and applies the same hashing function to the decrypted message. Ifthe hash value that Bob receives from his decrypted message matches the

hash signed by Alice, the message has not been tampered with. If Charleshad modified the message in transit, the hash values would be different andthe deception exposed. In this way the hash serves to verify the integrity ofthe message.

Cryptographic Security Functions

The use of Asymmetric Key Encryption and message digests forms thefoundation for security in today’s Internet communications. Cryptographicsecurity functions can be summarized by the following concepts.

Core Security Functions

• Privacy — Protecting information from unwanted or unauthorizeddisclosure. Privacy is provided by encrypting information using the publickey of the intended recipient; thus, it can only be decrypted with theprivate key of the intended recipient and no one else can read theencrypted message.

• Identity — The ability to identify the sender of a message. Because onlythe public key corresponding to the sender’s private key can decrypt thesignature, the identity of the sender can be guaranteed. In a PKI, publickey certificates are typically used for identity. (Public key certificates arediscussed later in this paper).

• Integrity — Protecting information from unwanted or unauthorizedmodification. The message digest (hash) operation allows a messagerecipient to verify that the content has not been altered duringtransmission.



Addi tional Secur ity Funct ions

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

• Authent ication — The ability to prove a claimed identity. Authentication isachieved 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 simpleas encrypting files, or as elaborate as a smart card containing a privatekey 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 uniquesignature on a contract is proof that he or she has agreed to its terms. Ifthat person were to deny (repudiate) it later, the contract holder would beable to point to the signature as evidence. In the digital world, a digitalsignature works in much the same way—the secret nature of the privatekey means that only one person could have signed the electronic

document containing that electronic signature.

The Value and Importance of the Private Key

Secure storage and protection of private keys is integral to the security of the Asymmetric Key Cryptography used in a PKI. If someone other than theactual holder of the key gains access to a private key, the entire PKI securitymodel breaks down.

For example, if Alice stored her private key in a file on her hard drive andCharles, a cunning hacker, steals the key, Charles can masquerade as Aliceand neither Bob nor Alice would be aware of the deception. If a private keyfell into the wrong hands, the new holder of the key could easily assume theidentity 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 signingauthority 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 pricequote to Alice signed by “Bob,” thereby winning the bid and causing Bobfinancial ruin. Alternatively, Charles could steal Alice’s private key and issuea false $1 million purchase order to himself that would appear to be signedby Alice.

In both cases, since only Alice and Bob should have had access to theirprivate keys, there would be some red-faces and explaining to do. Worse yet,Charles’ deception may go unnoticed for months, years, or never bediscovered at all.

Therefore, in a PKI environment, particularly one integral to businessprocesses, financial transactions, or access controls, it is essential thatprivate keys be guarded with the highest level of security possible.



The Role of the Certifi cate Authority and Certificates

In the PKI realm, the TTP is known as a Certificate Authority (CA) and theidentity assertions issued by the Certificate Authority are contained incertificates. Certificates are electronic files that contain information about theholder of the certificate. For example, a certificate might contain personal

information, such as the name, address, and public key of the certificateholder, information about the CA, and administrative items such as the typeof certificate and certificate expiration date.

If Alice receives a certificate from Bob, she could (using software) look at thecertificate, ensure that it is valid, verify the identity of the holder, anddetermine if she trusts the issuing CA before deciding to trust the assertionthat Bob is, in fact, Bob, and not Charles posing as Bob.

Certificate Authori ties and Trust

When a CA issues a certificate, it signs the certificate with its own private keyso 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 toidentify 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 responsiblefor signing its own certificate. In effect, the CA’s identity is entirely derivedfrom the sole fact that it is who it says it is, through a process called self-signing.

While there is nothing wrong with self-signing in this circumstance, it isimportant to note that the CA’s private key is very special. Because the CA’sprivate key signs its own certificate (during the self-signing procedure) andevery other certificate it issues, if the CA’s private key fell into the wronghands, every certificate ever issued by that CA using that private key couldno longer be trusted.

The Root Key

Because the CA’s private key is the anchor to the trustworthiness of allcertificates within a PKI, it is called the root key, owing its name to the factthat it is the root of trust for all the identities (certificates) in the PKI. Acompromise of the root key means that the network of trust inherent within astable PKI collapses. If Charles were to steal the root key of Contoso LTD,he could issue his own certificates to whomever he chooses. The certificatesissued by Charles would appear to originate from Contoso LTD, and Aliceand Bob could be fooled into trusting false certificates with disastrousconsequences.

Root CAs and Subordinate CAs

A PKI may contain several CAs to distribute the traffic load, or bring thecertificate signing CA closer to the point of issuance. In the latter case, the

CAs are usually arranged in a hierarchy, with a root CA holding the root keyat the top, and one or more subordinate CAs below it. Each subordinate CAcontains a unique private key, but this is not the root key. The subordinateCA’s identity is established with a certificate derived from the subordinateCA’s public/private key, signed by the Root CA’s private key. In this way, aTrust Chain is created, where a certificate’s authenticity can be traced backto the root key, even if the issuing CA is a subordinate CA rather than theRoot CA.



When subordinate CAs issue certificates, they sign the certificate with theirown private key. The recipient of the certificate can verify the authenticity ofthe subordinate CA by checking the validity of the subordinate CA’scertificate. While not holding the root key, the subordinate CA’s private keymust still be protected with the same precautions as the root key. If asubordinate CA’s private key were compromised, the loss of trust within thePKI would be devastating.

Because of the importance of the root key and the subordinate CAs’ privatekeys, to the operation of a PKI, they should be protected with the bestavailable physical, technological, and operational security. Hardware SecurityModules (HSMs) address these additional security requirements with securehardware to generate, store, and manage sensitive private keys.

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

Why an HSM is Important

As certificates have become essential components in electronic businesstransactions, the need to maintain the integrity of those certificates, and thePublic Key Infrastructure (PKI) as a whole, has increased. If a CA’s root keyis 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 theintegrity of the certificates, extraordinary caution should be taken to protectthe root key. For example, the storage of high value root keys should utilizespecialized hardware that is dedicated to preventing theft, tampering, andaccess to the secret key material.

A full-scale deployment of a PKI application, such as in a smart card accesscontrol application, secure email, or Secure Sockets Layer (SSL) Webservices used by thousands of employees or customers, may represent asignificant capital investment for an organization. Therefore, the investmentin a reliable, secure Hardware Security Module (HSM) should be considereda core component due to all of the associated processes, hardware, training,and operational costs relying on the foundation provided by a PKI.

HSM Functionality

As discussed later in this article, an HSM must maintain the integrity ofprivate keys in a PKI. An HSM should adhere to one or more recognizedsecurity 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 alsoaddress the requirements of reputable business processes and securityauditors to provide the highest degree of protection for the CA and its rootkeys.

In the deployment of a Microsoft Windows Server Certificate Authority, theco-deployment of an HSM is highly recommended to protect the CA rootkeys and maintain the integrity of the resultant PKI, certificates, and PKI-dependent applications.



For additional information on FIPS, visit the National Institute of Standardsand Technology’s Computer Security Resource Center Web site athttp://csrc.nist.gov/.

Overview of Luna HSMs

Operational Security

• The complete root key life cycle is contained within a Luna HSM secure,cryptographic hardware module, associated tokens, and validatedstorage module. Key material is never available at any time on the hostCA’s hard drive, tape backup media, system memory, or smart card.

Note: Key materials contained on a Luna HSM can be permanentlydeleted by reinitializing the token, although most audit proceduresspecify physical destruction of the token in order to be thorough andcomplete. It is also recommended that secure storage and materialaccess/audit controls be implemented to track all tokens.

• The Luna PED provides host-independent authentication.

• Built-in secure backup procedures for all physical materials, includingcryptographic hardware tokens and PED keys.

• SafeNet incorporates secure manufacturing, shipping, software update,and verification processes to maintain a trusted source for HSMhardware.

Rigorous Access Controls

• Provides host-independent access controls and authentication with theincorporation of the Luna PED (PIN Entry Device). The Luna PED is anHSM-attached keypad that avoids the risk of access codes beingcaptured from the host through key logging or other techniques.

• Three-factor authentication is made available with the mandatory use ofPED keys (key-shaped digital security devices), mandatory PEDpersonal identification numbers (PINs), and M of N key splitting(standard feature, installation optional.)

• Access controls are stored locally within the cryptographic hardwaretoken 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 theHSM when split-keys are used requires collusion between multiplepeople, greatly reducing the risk of insider attacks from rogueadministrators.



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 Validation

Administered by the National Institute of Security and Technology (NIST), theFIPS standard sets criteria for the physical and operational security ofcryptographic security modules. Differing levels of FIPS validation exist toaccommodate varying levels of security application requirements. FIPS

recognizes four levels (1-4) of validation corresponding to increasing levels ofsecurity in the device. For example, Level 2 provides a higher level ofsecurity than Level 1.

FIPS validation ensures that a device meets the high level of physicalsecurity required when protecting private keys resident on an HSM, includingtamper resistance, physical security, data integrity, and access controlmeasures. A Threat-Risk Assessment (TRA) from a security consultant canhelp 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 provideintrusion resistance and tamper evidence in secure environments.

•

In addition to an ongoing commitment to producing FIPS-validatedproducts, SafeNet is incorporating the requirements of emergingstandards, including Common Criteria and FIPS, to ensure its productsmeet the future security requirements of its customers.

Hardware-secured key generation

Due to the inherent difficulty in completely securing the Ham’s host server orhost application from a physical attack or theft, the private key generationshould be performed within the confines of a HSM. If a private key isgenerated on the Ham’s host server, there is a chance that the private keycould be captured or deduced if the host CA system is physicallycompromised.

• The Luna HSM generates all keys, including private keys, within a

secure cryptographic hardware token.

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



Hardware-secured Key Storage

To ensure the integrity and security of high value private keys, they aresecured at all times by the HSM. If the private key in plain text or encryptedfile 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, orotherwise tampered with should an attacker gain physical control of the host

system. Most often, this is attempted through a Trojan horse attack involvinglocal physical installation of rogue software. Once copied, an attacker canlocate and analyze the plain text private key at leisure. If the private key iscompromised or the only copy the of the key is deleted, generation of a newprivate 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 privatekeys, the private key material is never transferred to the host server'smemory or stored on its hard drive.

Hardware-secured Key Backup

It is recommended that backup copies of private keys be made for securityand disaster recovery purposes. However, given the sensitive nature ofprivate keys, the same precautions that apply to private key storage mustalso be applied to the backup copies.

Storing private keys in plain text or encrypted file format on vulnerablebackup media, such as magnetic tape, floppy disks, or optical media, doesnot provide adequate security. So that the private key remains under strictcontrol and is never exposed outside of the HSM, the Luna HSM backs upkey material to secure hardware devices.

Hardware-secured Digital Signing

If cryptographic operations, such as certificate signing, are performed on thehost server, the private key must first be transferred out of the HSMenvironment to the host server. Due to the difficulty in completely securingthe host server (which is usually attached to a network), the keys may bevulnerable if the host server is physically compromised. Therefore, bestpractices recommend that all operations requiring the private key beperformed within an HSM.

• The Luna HSM performs all cryptographic operations within a securehardware token in order to maintain the integrity and security of theprivate key when it is used in cryptographic processes.

• Luna HSM cryptographic hardware offloads processor-intensivecryptographic chores from the host server, providing a significant

increase in signing performance, through the use of dedicatedcryptographic hardware processors.



PKI-authenticated HSM Software Updates

To prevent insertion of malicious software code into the HSM, the HSM'ssoftware and firmware must originate from a trusted source and be deliveredvia a trusted path to maintain integrity. HSMs use a combination of hardware,hardware-resident firmware, and software to perform their tasks. During themanufacture of the HSM, it is necessary to initially program the firmware.

Once programmed, the HSM's firmware and software may be updated to addfunctionality. Because firmware has low-level access to the HSM's hardware,it is essential to prevent unauthorized insertion of software code in order tomaintain the integrity of the HSM.

• SafeNet provides rigorous controls over the manufacture, programming,and maintenance of software code that is placed on Luna HSM securecryptographic tokens.

• SafeNet hardware components are programmed using an irreversibleanti-fuse process to prevent tampering with the onboard algorithms.SafeNet then uses a specialized firmware encryption process to load andverify the firmware on the token. Once programmed, the firmware isverified on every boot using a CRC (cyclic redundancy code) computed

from the original firmware image.

• Hardware design, software development, component assembly, andshipping are all carefully controlled processes that are thoroughlymonitored for security.

• After manufacture, SafeNet continues to protect the integrity of tokenfirmware during firmware updates. Firmware update images areencrypted with a randomly-generated key protected by a key derivedfrom the customer's unique authorization code. This protected key datais contained within a cryptographic header, signed with the SafeNetmaster 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 updateprocess on the token ensures that the updated image is fully andcorrectly loaded before it is allowed to execute.

Host-Independent, Two-Factor Authentication

Login and authentication procedures are performed independent of the hostserver, using two-factor authentication through a trusted connection path tothe HSM.

To prevent the compromise of private key access controls, SafeNetrecommends that the host server not perform access and authenticationoperations pertaining to private key operations. Security exploits to the host,such as keystroke loggers, may allow access control information to becaptured and exploited. SafeNet provides the Luna PED, a handheld, host-

independent authentication device to address this concern.



Additionally, two-factor authentication is essential in preventing unauthorizedaccess to the HSM. Two-factor authentication requires two of the followingthree types of items to be present for authentication to occur:

• Something you know —knowledge of secret data. For example, aPersonal Identification Number (PIN) or password.

•

Something you have —a unique physical item possessed only byauthorized individuals. For example, a security identification badge.

• Something you are —a unique physical characteristic possessed by anauthorized 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 difficultto gain unauthorized access. For example, while an ID badge may be lost orstolen, the requirement for a PIN or biometric makes the ID badge uselesson its own. The use of two-factor authentication provides strongauthentication protection for the HSM.

Luna HSM Features

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

• The Luna PED provides two-factor authentication by requiring that aPED key, a key-shaped identification token containing digitalauthentication data, and an associated PIN be entered beforeauthentication can occur and access to the HSM is granted.

Enforced Operational Roles

To prevent unauthorized, unilateral actions by a single person, operationalroles are split so that no one individual has too much operational control.

Access controls are often used to prevent outside access to resources withinan organization, but trusted people within an organization commit a largepercentage of computer crime. Concentration of administrative power into thehands of a single “trusted” user makes it easier for that user to damagesystems. It is recommended that operational and administrative roles bedivided among several people in order to prevent unilateral action.

Luna HSM Features

• Luna HSM differentiates between five roles that are typically presentduring the life of an HSM through the use of different PED keys forauthentication:

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

• The blue PED key is used by the security officer for tokenconfiguration 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 LunaHSM token to another.



• The green PED keys are used for secret sharing with M of N accesscontrols.

• No individual holds more than one key, thereby forcing collusion betweentrusted 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 privatekey stored on the secure cryptographic token can be accessed, thusdecreasing the risk of collusion between operators even further.

Applying Luna HSM Features and Benefi ts inOperational ScenariosThe need for high value root key protection is undeniable. However, using asecure HSM, and observing best practices during HSM operations andmaintenance, maximizes root key integrity and virtually eliminates the risk ofcompromise. The combination of an HSM, coupled with strong operationalpractices, 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 protectPKI deployments from a range of security threats.

Scenario 1: A Rogue Administrator

Most security breaches are the act of a trusted employee who has easyphysical and login access to computer resources. These employees may bemotivated to compromise the integrity of the PKI due to job dissatisfaction orexternal influence. Internal attackers are very familiar with the systems theyare trying to compromise, often being directly involved with day-to-dayoperations, and possibly having user-level access rights that would allowthem 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 toolate.

A rogue administrator can wreak havoc on an unprotected HSM that doesnot follow best practices, possibly leading to the collapse of trust within thePKI. Using personal access privileges, a rogue administrator can steal,delete, or copy the root key, sign new certificates, or even cause physicaldamage to the HSM itself. While certain security breaches are immediatelyapparent, others, such as copying, may go undetected, allowing acompromised HSM to continue to sign certificates.

Luna Solution

• Division o f Operational Roles —Luna HSMs divide the operationalroles among several people within an organization. Through the

mandatory use of the Luna PED and its associated PED keys, the LunaHSM recognizes five types of users, each with access to specific rootkey operations, limiting an individual’s ability to compromise the root key.For example, while an administrative user (possessing a blackadministrator PED key) may be able to access the root key and performkey operations, this person would be unable to delete or copy it becausethese operations require the grey initialization PED key and redgroup/cloning PED key respectively.



• M of N Split-key Authentication —Prevents unilateral action byrequiring multiple (M) people possessing parts of a shared key (N) toagree to a course of action. M of N split-key authentication requirescollusion between several people before action can be taken. FIPS Level3 Luna HSMs includes M of N access through the Luna PED as anoptional level of access control.

• FIPS Level 3 Validation —The intrusion-detection and tamper-evidenthousing of a Luna HSM provides a robust defense against direct physicalattack. The secure cryptographic tokens holding the root key can befurther protected with the optional Luna Lock to prevent unauthorizedremoval.

Scenario 2: A Compromised Certif icate Authority

The very nature of the CA server requires, in most installations, an activenetwork connection in order to issue certificates. This network, in turn, maybe connected to, or be accessible from, the Internet. Because of theopenness inherent in most network protocols, and the large number ofmalicious hackers roaming the Internet, the CA then becomes a potential

target for deliberate or incidental attack from virus, denial of service, andsecurity exploit attacks. If the root key is stored in plain text or encrypted fileformat on the local hard drive or other accessible media, it may becompromised during an attack through deletion, duplication, or alteration.

Additionally, sniffer programs (a Trojan horse application designed to collectdata) may be placed on a compromised system in an attempt to extract theroot key, in clear text, from the CA system RAM, or a key logger may beinstalled to capture login access information. Due to the silent nature of mostelectronic crime, these breaches may go undetected for some time, seriouslycompromising the integrity of the CA and the PKI around it.

Luna Solution

• Secure Hardware Root Key Storage —The root key is protected at all

times within the Luna HSM.• Trusted Path Au thentication —Luna HSMs uses the Luna PED, not the

host CA system, for access control and authentication. The Luna PED isconnected directly to the Luna HSM to create a “Trusted Path” forauthentication and to eliminate the possibility of PINs or login informationbeing captured with key loggers resident on the host CA server.

• Dedicated Hardware Certificate Signing —All cryptographic processesthat use the root key are performed within the Luna HSM. The root key isnever transmitted to the host CA where it could exist in an unprotectedplain text state in system RAM and become vulnerable to snifferprograms or buffer overflow exploits.



Scenario 3: Disaster Recovery

The importance of the root key mandates that it be safely backed up topermit quick recovery from a failure state. In the event of a failure of the hostCA or HSM, it is necessary to ensure that the key is easily restored asquickly 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 ontocommon media, such as a hard drive or magnetic tape, the private key maybe accessible from these insecure media through data extraction techniques.

Additionally, during the deployment of multiple HSMs in a high-availabilitycluster, it may be necessary to copy the root key to additional HSMs whileusing a secure, trusted path between the devices.

Luna Solution

• Secure Hardware Root Key Backup —The Luna HSM backs up theroot key directly from the HSM to a secure Luna hardware backupdevice, ensuring that the root key is always maintained in a secureenvironment. The backup device can inherit the same access controls asthe HSM itself to prevent unauthorized access to the backup, and sincethe backup device is tamper-resistant, the integrity of the backup rootkey is protected.

• Arrays of Luna HSMs can be established using either backupdevices or network cloning —This permits easy installation of high-availability HSM clusters in data center environments. Access controlsare propagated to the backup device, preventing unauthorized accessand creating a controlled duplication of the root key across multipleHSMs, as required.

• Luna HSMs are independent of the host CA computer —A hardwarefailure on the host CA does not affect the Luna HSM. Once areplacement CA system is brought online, it can be quickly registeredwith the Luna HSM to continue PKI operation. In the case of a network

shareable Luna HSM, there may be clustered CA servers sharing one ormore Luna HSMs to provide extremely high levels of system availability.



Luna PED and PED KeysThe Luna PED provides direct access andauthentication to a Luna HSM, eliminatingthe need to log on through a potentiallyunsecure computer. As previously

discussed, the Luna PED uses two-factorauthentication to provide a high degree ofsecurity. Two-factor authenticationrequires that two of three elements bepresent before authenticating an

individual. To review, these elements may be:

• Something you have —a unique item thatserves as a security token. An example wouldbe a key, bank card, or ID badge.

• Something you know —knowledge of a secret required forauthentication; for example, a Personal Identification Number (PIN) orpassword.

• 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 difficultto gain unauthorized access. A stolen security badge is useless without thecorresponding PIN. A misplaced PIN will not function without the PIN holder’sfingerprint.

The Luna PED provides two-factor authentication through the use of a PEDkey and an optional PED PIN. Additionally, a third factor may be addedthrough the use of M of N key splitting.

PED Keys

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

• Physical Security —The key-shaped design of the PED key is requiredto operate the key slot on the Luna PED during authentication.

• Authent ication Token —The PED key functions as a unique physicalauthentication token (something you have) during authentication. EachPED key is imprinted with a unique digital identifier specific to the LunaHSM during the initialization process.

• Division o f Operational Roles —The PED keys allow for division ofoperational roles. Each PED key corresponds to a different role in the

administration hierarchy of the Luna HSM, ensuring that no singleindividual has too much operational control.

The Luna PED two-factor

authentication device and a

set of PED Keys.



What PED Keys Do

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

• Grey (Initi alization) Key —Mandatory. Generally used only once, thiskey is needed to initialize the Luna HSM.

• Blue (Security Officer) Key —Mandatory. This key is possessed by thesecurity officer (SO) whose role is defined by your corporate securitypolicy.

• Red (Group/Domain/Cloning) Key —Mandatory. This key sets themembership of a token to a defined domain, or permits the cloning ofone token’s contents to another. A red key is mandatory, but a shareddomain is not.

• Black (User) Key —Mandatory. Defines users who have access toadministrative functions of the token.

• Green (M of N) Keys —Optional. These keys are used to set M of Naccess policy. M of N keys require that a defined number of sharedsecret keys (N) be present (M) before an administrative action can beperformed, preventing unilateral actions.

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



SafeNet OverviewSafeNet (NASDAQ: SFNT) is a global leader in information security.Founded more than 20 years ago, the company provides complete securityutilizing its encryption technologies to protect communications, intellectualproperty, and digital identities, and offers a full spectrum of productsincluding hardware, software, and chips. ARM, Bank of America, Cisco

Systems, the Departments of Defense, and Homeland Security, Microsoft,Samsung, Texas Instruments, the U.S. Internal Revenue Service, and scoresof other customers entrust their security needs to SafeNet. For moreinformation, visit www.safenet-inc.com.

w w w . s a f e n e t - i n c . c o m

Corporate Headquarters: 4690 Millennium Drive, Belcamp, Maryland 21017 USA

Tel: +1 410.931.7500 or 800.533.3958 email: [email protected]

Aus tralia +61 3 9882 8322Brazil +55 11 6121 6455Canada 613.723.5077 China +86 10 8266 3936Finland +358 20 500 7800France +33 1 41 43 29 00Germany +49 18 03 72 46 26 9Hong Kong +852 3157 7111India +91 11 26917538

Japan(Tokyo) +81 3 5719 2731Korea +82 31 705 8212Mexico +52 55 5575 1441Netherlands +31 73 658 1900Singapore +65 6297 6196Taiwan +886 2 27353736UK +44 1276 608 000U.S. (Massachusetts) +1 978.539.4800U.S. (New Jersey) +1 201.333.3400U.S. (Virgi nia) +1 703.279.4500U.S. (Irvine, California) +1 949.450.7300U.S. (Santa Clara, California)+1 408.855.6000U.S. (Torrance, California)

+1 310.533.8100

Distributors and resellerslocated worldwide.

Phone USA and Canada (800) 533-3958Phone Other Countries (410) 931-7500Fax (410) 931-7524Email [email protected] Web site www.safenet-inc.com

©2004 SafeNet, Inc. This document contains information that is proprietary to SafeNet, Inc.No part of this document may be reproduced in any form without prior written approval by

SafeNet. SafeNet shall have no liability for errors, omissions or inadequacies in the informationcontained herein or for interpretation thereof. The opinions expressed herein are subject tochange without notice.

Wp Pki IntroPKILuna

Documents

Transcript of Wp Pki IntroPKILuna