A PUBLIC KEY INFRASTRUCTURE (PKI) and encryption are used by everyone, every day. Employing the technologies and algorithms associated with them provides a secure system for transmission of data, whether the data is at rest or in motion. Ensuring the appropriate encryption algorithm is used for appropriate services will help provide a secure environment.
This chapter covers the essentials of PKI: what it is, how it works, implementation security levels, and how it is supported.
A public key infrastructure is important because it provides secure mechanisms for business and e-commerce transactions. It provides a community of trust. Through this community of trust, people are able to browse the Web more securely, send secure e-mails, and download safe software. PKI does not solve all security issues, and it does not make all software safe or ensure Web sites do not have malware embedded in them. However, it does provide an infrastructure to make the Internet safer, and it provides a level of security that is needed for a multi-layer security system within an organization.
Note
Public key cryptography and PKI are different. Public key cryptography is also referred to as asymmetric cryptography. PKI is an infrastructure for the secure distribution of public keys that are used in public key cryptography.
A public key infrastructure (PKI) is a framework that consists of programs, procedures, and security policies that employs public key cryptography and the X.509 standard (digital certificates) for secure communications. PKI is a hybrid system of symmetric and asymmetric key algorithms. It is also an infrastructure that identifies users, creates and distributes certificates, maintains and revokes certificates, distributes and maintains encryption keys, and enables technologies to communicate via encrypted communications. PKI relies on a level of trust within this framework in order for it to be successful and secure.
Components of a public key infrastructure are:
Certificate authority—An entity, normally a trusted third party, that issues digital certificates for identities. A certificate associates the identity of a person or server with the corresponding public key.
Registration authority—An entity that is responsible for the registration and initial authentication of users who are issued certificates after a registration request is approved. These users are also called subscribers.
Certificate server—The machine or service responsible for issuing digital certificates based on the information provided at the registration process. The certificate server is a component of the certificate authority.
Certificate repository—A database that stores the digital certificates belonging to users of the PKI.
Certificate validation—The process of determining that a certificate is valid and can be used by the user for their specific needs.
Key recovery Service—The service that archives and recovers encryption keys.
Time server—A server that provides a digital timestamp for use by the services and applications.
Signing server—A server that provides central digital signing and verification services.
Essentially, a PKI provides services that protect confidentiality, integrity, authentication, and non-repudiation of information exchanged between parties. You'll learn about these important concepts throughout this chapter.
A PKI provides the capability to distribute public encryption keys while keeping the decryption keys private. In order to understand PKI, it is important to understand the background of encryption and therefore how PKI came to be.
Encryption is the process of applying an algorithm to clear-text (or plaintext) data, resulting in ciphertext. To a user attempting to read the ciphertext without the decryption key, it appears random and unreadable. In order for any system or user to read the ciphertext, the data needs to be decrypted, resulting in the original clear text. Figure 13-1 shows this process.
In previous chapters, you learned about controls that allow or deny access to data on systems and networks. But how do you protect that data while being transferred from one system to another or while it is at rest? Encryption ensures that only those with the appropriate decryption key can view the data.
A cryptosystem is a hardware or software system that provides encryption and decryption. The cryptosystem is made up of the encryption algorithm, keys, and the software and protocols. The algorithm determines how the encryption and decryption will take place. Examples of symmetric encryption algorithms are Data Encryption Standard (DES), Triple Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). Examples of asymmetric algorithms are Rivest, Shamir, and Adleman (RSA), Diffie-Hellman, and Elliptic Curve Cryptosystem (ECC).
The details of these algorithms are publicly available. Therefore, in order for them to allow the secure exchange of information, some other component of the cryptosystem must be unknown or secret. The secret piece of the cryptosystem is the key. The algorithm can be known to everyone and can be posted anywhere, but it is the key that unlocks all the information. The ciphertext is only secure if the key is kept secret. In encryption, the key is a value that consists of a large sequence of random bits. The keyspace is the range of values that construct the key. When the algorithm creates a new key, it uses the values that have been identified through the keyspace. A large keyspace means that more keys are possible. The more keys that are possible, the harder it becomes for an attacker to figure them out.
The strength of the encryption comes from the secrecy of the key, although key length, the algorithm, and all of the components working together make the encryption even stronger. In order to break a cryptosystem, an enormous amount of processing power must be used to determine the one key that can decrypt the system. The strength of the encryption is proportional to the amount of processing it takes to determine the value of the key.
Brute-force attacks can be used to break a cryptosystem. This means that every key will be tested in order to find the correct one. The length of the key and the algorithm will determine the amount of keys that will need to be tested to break the system. In order to create a strong encryption implementation, one must use a long key drawn from the full pool of all keyspace values, as well as ensure the key is secure. Keys that are 128, 256, 512, 1,024, or 2,048 bits are considered "long."
Chapter 11 covered symmetric and asymmetric encryption in relation to Secure Sockets Layer (SSL) 128-bit encryption for e-commerce portals. Let's review those concepts before identifying their relationship to PKI.
Symmetric algorithms use shared secret keys for encrypting and decrypting data. Both the sender and receiver use the same secret key. If an attacker were to obtain the secret key, he or she would be able to read the data and the information would no longer be considered secure. Protecting the secret key is essential to the strength of the system. If the key is compromised, the messages sent with that key are compromised. Symmetric cryptosystems provide confidentiality in that they only allow the users who have the secret key to read the data. The strengths and weaknesses associated with symmetric key systems are:
A symmetric key system encrypts and decrypts information faster than an asymmetric system.
A symmetric key system requires a secure method to create and exchange the secret key.
Each pair of users requires a unique key, and therefore key management becomes difficult as the number of pairs of users increases. For instance, if John wants to communicate with Kelly, they both need to obtain a copy of the same key. If John, Jack, and Kelly all want to be able to communicate privately with each other, three keys are needed—one for John and Jack, one for John and Kelly, and one for Jack and Kelly. If John wants to communicate with 50 people, 1,225 keys are needed. The determination of the amount of keys needed is provided by the following equation, where n is the number of people participating in the cryptosystem:
n (n− 1) / 2 = number of symmetric keys
Figure 13-2 shows how a symmetric key algorithm is used in the encryption process.
Asymmetric algorithms use pairs of related keys, a public and private key for the encryption and decryption process. A public key can be known by everyone, but the private key can only be known or used by the owner. Public keys can be distributed to anyone in any mechanism. There is no need to protect the secrecy of the public key. Often, a public key is available through directories or databases of e-mail addresses.
Warning
Although you can encrypt data with either key, remember that you can only obtain confidentiality by encrypting data so that a private key is required to decrypt it. Therefore, any time you want to send a secret message, you must encrypt it with the recipient's public key. Encryption with private keys is only done for purposes of authentication or non-repudiation, such as in digital signatures.
The public and private keys are mathematically related such that anything encrypted with one can only be decrypted with the other. In a strong cryptosystem, someone who has the public key can not use it to determine the private key. Asymmetric cryptography can provide confidentiality by having the sender encrypt the data with the receiver's public key. This ensures that only the receiver can decrypt it because the receiver is the only one who knows the receiver's private key.
Asymmetric cryptography can also provide authentication when the sender encrypts data with their own private key. After the receiver decrypts the message with the sender's public key, they know that it could only have come from the sender's private key. Note that from Figures 13-3 and 13-4, a public key can be used for both encryption and decryption. If data is encrypted with a public key, it can only be decrypted with the private key. If data is encrypted with the private key, it can only be decrypted with the public key. Asymmetric encryption uses public/private key pairs, with each user having his or her individual pair. Therefore, you need two keys for every user in the cryptosystem.
The strengths and weaknesses associated with asymmetric key algorithms are:
Asymmetric systems have better key distribution and scalability compared with symmetric key systems.
Asymmetric key algorithms provide confidentiality, integrity, authentication, and non-repudiation.
Asymmetric key systems are slower than symmetric key systems because they use more complex mathematics during key creation, and when encrypting and decrypting data with those keys.
Businesses require cryptography for multiple uses within an organization. Common examples of cryptography include the protection of internal data from external parties, preventing insiders from seeing information that they shouldn't have access to, and ensuring that customer transactions are authenticated.
Some of these requirements for cryptography within businesses are:
Ensuring software and data integrity
Ensuring secure collaboration between entities inside and outside an organization
Secure cloud computing
Providing secure transactions with consumers
Ensuring software and data integrity means that software remains secure as it is being developed, and that software that consumers download is secure. Organizations have various developers sign the software as it is being created to ensure its security. Keeping track of these signatures helps organizations know what code was added, when, and by whom. This provides for secure software development and ensures that malicious code was not included in the software without the developer's knowledge.
Secure collaboration within and outside an organization protects communications between multiple entities. It also protects the communication against attackers. Ensuring trusted communication between entities is vital for organizations to ensure their data is secure and only seen or received from trusted users.
Figure 13-3. Example of asymmetric key encryption process, encrypting with public key for confidentiality.
Figure 13-4. Example of asymmetric key encryption process, encrypting with private key for authentication.
With the implementation of cloud services, businesses want to ensure that data kept in the cloud is secure and not able to be retrieved or seen by unauthorized users. For example, an organization may choose to store specific data on a cloud provider's server, but the organization needs to be sure that its data will be just as secure in the cloud as it would on-site. Employing cryptography will ensure that users or the provider cannot view the data without the appropriate keys. Cryptography is just one step used in addressing the overall concern with cloud providers and the implementation of cloud services.
Many organizations conduct transactions with their customers as a part of doing business. An organization must ensure there is security associated with these transactions. Cryptography provides this business requirement by protecting transaction communications and ensures both the organization and the customer are secure. Not employing this security measure may result in customer dissatisfaction and low confidence. This risk of losing customers is not something an organization wants to take on.
A digital certificate is used to associate a public key to a uniquely identified owner. The standard for digital certificates is X.509, which identifies the fields and values to be used in the certificate. These fields include:
Version of the certificate
Unique serial number associated with the certificate
Algorithm ID used to sign the certificate
Name of the certificate issuer
Validity dates of the certificate
Name of the owner of the certificate
Public key of the owner
ID of the issuing certificate authority
ID of the owner
Optional extensions
Figure 13-5 shows an example of a digital certificate.
A registration authority (RA) verifies the identity of an individual, initiates the certification process with a certificate authority (CA) on behalf of the user, and performs certificate life-cycle management. When a user requires a new certificate, the request is made to the RA, and the RA verifies all necessary information before the request is made to the CA.
Key management ensures the security of the cryptographic keys through the key's life cycle. Components of key management are:
Key generation—The initial creation of keys. The technical accuracy behind the creation of symmetric and asymmetric keys is fundamental to key management. Ensuring the randomness of the keys increases the strength of the cryptographic system of the entire PKI.
Key distribution—Moving keys from one point to another. There are two stages for key distribution: initial and subsequent. Establishing a key in a secure manner is essential to the overall security of the PKI system. The initial key is used to distribute other keys. The subsequent keys are securely exchanged using the initial key.
Key usage—When keys are in a production environment and being used for e-mail, file transfers, secure connections, and so on.
Key recovery—Restoring a key after a failure has occurred to key storage. If the hardware or software associated with key storage fails and a new system is acquired, the keys will need to be recovered.
Key termination—The destruction of keys because they have reached the end of their life cycle or because a key has been compromised in some fashion.
Key archival—Retaining a key that has been terminated. A copy is kept in a key storage for validating data that was protected by the original key.
Each of these components of key management is vital to a PKI system. Failure of one of these components will jeopardize the security of the entire PKI system. One of these may be considered more important than another depending on what is being protected, but the lack of execution for any of them will result in an unsecure system.
Some additional considerations with regard to key management that help to provide a secure PKI system are:
The key length should be long enough to provide the necessary level of protection.
Keys should be random and the algorithm should use the full keyspace.
A key's lifetime should correspond with the sensitivity of the data, for example, a highly secure piece of data should have a short key lifetime.
The more a key is used, the shorter its lifetime should be.
Symmetric and asymmetric encryption algorithms are varied in many ways. You just learned about a few ways they can be used and implemented. A major differentiation outside of the ones discussed is the key length. Asymmetric cryptography requires a longer key length in order to achieve the same level of security that is achieved through symmetric cryptography.
Note
Alice and Bob are commonly referenced names when discussing cryptography. These names represent Person A and Person B.
Whitfield Diffie and Martin Hellman introduced the first asymmetric cryptography algorithm in 1976. It was developed for the distribution of symmetric keys and is based on the mathematics of discrete logarithms in a finite field. The Diffie-Hellman key exchange enables two systems to receive symmetric keys without a previous communication. It provides key distribution but does not provide encryption or digital capabilities. The following example will help you further grasp the Diffie-Hellman algorithm.
Mathematically, Diffie-Hellman looks like this:
Alice and Bob agree to create a key using a randomly generated prime number (p) and a common integer base (g).
Alice selects a private key (a) and uses it to compute her public key (A) with the formula ga mod p. Alice makes g, p, and A public—these three numbers make up the public key—and keeps a private.
When Bob wants to communicate with Alice, he finds her public key and computes some values. He generates a random exponent (b) to build a public key (B) by computing gb mod p. He uses the same g and p from Alice's public key.
Once Bob creates b and B, he builds the secret value (s) by computing Ab mod p. Alice can compute the same secret value using the information she has and the formula Ba mod p.
Alice and Bob can now communicate using any symmetric algorithm of their choice and the shared secret key s.
The RSA asymmetric encryption algorithm was developed to resolve man-in-the-middle attacks. The RSA algorithm is named after its inventors Ron Rivest, Adi Shamir, and Len Adleman. It is the most popular public key algorithm available and can be used for digital signatures, key exchange, encryption, and decryption. The algorithm is based on factoring large numbers that are a product of two prime numbers. When used in a PKI system, the cryptosystem generates a symmetric key using a symmetric algorithm such as AES. The cryptosystem encrypts the symmetric key with the receiver's public key. Only the receiver will be able to decrypt the message via the use of his or her private key and be able to retrieve the symmetric key.
Elliptic curve cryptosystem (ECC) provides much of the same functionality as the RSA algorithm such as digital signatures, secure key distribution, encryption, and decryption, but it is more efficient than RSA. The algorithm computes discrete logarithms of elliptic curves. ECC provides the same level of security as the RSA algorithm but with a smaller key.
Table 13-1. Symmetric versus asymmetric attributes.
ATTRIBUTE | ASYMMETRIC ALGORITHMS | SYMMETRIC ALGORITHMS |
|---|---|---|
Keys | Public key is available to all; private key is kept secret to the owner and never shared | One key is shared between two or more entities |
Example algorithms | RSA, Diffie-Hellman, ECC | DES, 3DES, AES |
Key exchange | Easy to deliver public key | Requires sharing keys in advance through another secure mechanism. |
Encryption speeds | Slower | Fast |
Security services provided | Confidentiality, integrity, authentication, and non-repudiation | Confidentiality, integrity, and authentication |
When a smaller key is used, less processing is required when implementing the ECC algorithm. Providing the security level with less processing means the algorithm can be used by devices with limited power, bandwidth, storage, and capacity, such as mobile phones.
A synopsis of these attributes is provided in Table 13-1.
A CA is a trusted organization that maintains, issues, and distributes digital certificates. When a user requests a digital certificate, the RA verifies the user's identity and sends the request to the CA. The CA creates the certificate, signs it, sends it to the user, and maintains it over the life of the certificate. When another user wants to communicate with the user, the CA will vouch for the user.
CAs can be internal to an organization, which allows the organization to have complete control over the distribution and life of the certificate. The CA can also be provided by a third party such as VeriSign. An example of a listing of trusted certificate authorities is shown in Figure 13-6. If a certificate ever needs to be revoked, the information is stored in the certificate revocation list (CRL).
The following example illustrates a CA used in a PKI system:
Alice makes a request to the RA.
The RA requests certain information from Alice such as her phone number, address, and other identifying information.
The RA verifies the information and sends the digital certificate request to the CA.
The CA creates a certificate with Alice's public key and information embedded. The public/private key pair can be generated by the CA or on Alice's machine. If the CA creates it, it must be transferred securely. The CA signs the certificate with the CAs private key. Alice can now participate in a PKI.
Bob wants to send a message to Alice, so he requests her certificate.
Bob receives the digital certificate from Alice.
Bob uses the CAs public key to verify the digital signature. If the signature authenticates, he extracts Alice's public key from the certificate and uses it to communicate with her.
Note
You'll learn more about CAs later in this chapter.
This process is shown in Figure 13-7.
A PKI system uses symmetric and asymmetric encryption algorithms and digital certificates to provide security for multiple applications and uses. It provides a more secure environment for both organizations and end users. The security that is provided through PKI relies on processes and services that are fundamental. These security services allow for a secure solution to be developed for delivery of information across the Internet. The security services are:
Integrity is provided in PKI through cryptographic methods such as digital signatures or a message authentication code. It ensures that the document or data that was received was not tampered with or altered. It ensures the receiver is receiving the message in its original format. If Bob wants to ensure that a document received by Alice was what he was intended, a fingerprint of the document is provided. If the fingerprint matches, the document was not altered. This capability is often used by users when downloading applications. If Bob is downloading a new version of an Internet browser, he wants to ensure that it is the software the manufacturer produced. He wants to verify that no one was able to intercept it during transit and apply additional components to it such as malware. Any change to the software would create a new fingerprint, and Bob would know that the software should not be installed. The message and fingerprint are closely tied, and to find a pair that has the same fingerprint is highly unlikely.
Confidentiality is provided in PKI through encryption. It ensures that the receiver is the only user that can see the data or message after it has been sent. In a PKI, if Bob chooses to encrypt a message with Alice's public key, he knows that only Alice is able to read the message because she is the only one who holds her private key. A user's private key is not shared.
Authentication is provided in PKI via digital signatures or encryption. Signing a document or data provides the process to identify who the signer is. Digital signatures are retrieved through the community of trust. If you trust the creator of the digital signature, you can trust the authentication process the sender went through to obtain the digital signature.
Non-repudiation is the concept of ensuring an originator cannot refute the origin of a statement or document. Non-repudiation can be provided through the use of digital signatures. When Alice digitally signs a document, Bob is assured that the document came from her because it was encrypted with her private key, which only she maintains. Alice cannot deny that she sent it because her private key was used. This is non-repudiation. If Alice claims that her private key was stolen and she did not send the document, the timestamp is referenced. The time that the digital signature was executed must be encoded into the document before the cryptographic hash function is applied (which you will learn about in the next section). If the document changes in any way, the verification of the signature will fail. It is important that the time source be secured when digital signatures are used for non-repudiation. One must ensure that the time source can be trusted and is secure in order for non-repudiation to be successful.
Digitally signing an e-mail allows the receiver to verify the contents have not been modified after the data was sent. Digital signatures also provide non-repudiation, that is, they allow the recipient to conclusively prove to a third party that the sender actually sent the message. Digital signatures can also be used to identify if a user has "signed off" or approved a particular document.
Creating a digital signature requires that a cryptographic hash function be applied to the message, resulting in a message digest or hash value. The original hash value is encrypted using the signer's private key and decrypted using the signer's public key.
If the two hash values match, the signature is verified. When the sender's e-mail client appends the digital signature to the original message, the sender is digitally signing the document. Figure 13-8 walks you through the signing process.
Verifying the digitally signed document requires the receiver to apply the same cryptographic hash function to the document in order to produce the message digest or hash value. The hash value in the digital signature is decrypted with the signer's public key. If the two hash values match, the digital signature is verified. This process is illustrated in Figure 13-9.
PKI is a framework used to build a secure infrastructure. It employs many capabilities but can be mistakenly considered the answer for all security within an organization. There are many truths and misunderstandings associated with PKI, which are covered in this section.
PKI is a strong authentication mechanism. The binding of a user to a key pair means that the key pair can be used for digital signing. This task would be difficult in symmetric encryption, for example, because of the need for a new key for each message authentication code. Employing PKI for digital signatures means that a single signing key can be used for multiple documents over a relatively long period of time.
PKI provides a mechanism for ensuring what is being downloaded or read has not been altered. For example, PKI helps protect data from attackers and ensures that attackers are not able to break the communication link and alter the data as it is transmitted over a network. This is beneficial for organizations, particularly if end users are able to download their own software. Ensuring that software has not been altered during the download process ensures the end user and the organization that malware was not injected into the software after the download process began.
PKI provides integrity, confidentiality, authentication, and non-repudiation in a single framework. PKI is a necessary entity in a defense-in-depth security structure. Employing the appropriate software, hardware, policies, and community of trust to protect communications between entities within or outside of the organization is paramount to protecting the organization in itself. It protects not only the users of an organization but the consumers that use the organization's products and services. For example, when downloading software, PKI protects Microsoft as much as it protects the user. The user wants to ensure he or she is downloading the correct software from Microsoft, but Microsoft wants to ensure this too. If there was not a capability provided to ensure integrity of the data, a user could accuse Microsoft of injecting malware into the software. Microsoft would not be able to prove this was or was not the case. By comparing the hash values of the correct software and the downloaded software, Microsoft can prove what software they developed and intended to be downloaded.
PKI is not an answer to all security questions or concerns. You cannot encrypt all data and communications and assume that everything is fine. Security within an organization requires multiple layers, and PKI is just one layer within the security platform. PKI will not stop attacks on an organization, it will not prevent the downloading of malicious code, and it is not a firewall. PKI does not stop users from making security mistakes. Users will still download software that leaves network ports open, write down passwords, or mistakenly download viruses or Trojan horses to their computer systems. The mere use of a PKI does not ensure an organization is implementing the necessary access controls, training, and standard configurations that help secure an organization.
PKI does not provide authorization. It may authenticate a particular user, but it does not distinguish what that user can or cannot do within the system. Additional tools and capabilities are needed to address this need within an organization.
PKI does not ensure that the end user can be trusted. PKI employs a community of trust, but it should not be mistaken for trusting the user. For example, Alice trusts that the data she received was sent from Bob, but this does not mean that Bob should be trusted or the specific information he provided is accurate. This understanding is important when downloading software. You may trust Microsoft and therefore you feel comfortable downloading its software. This trust you established was built over time. This may not be the case with other unknown software manufacturers. Just because the data was digitally signed does not mean the original software is secure and that malware has not been incorporated from the start.
Note
Trusting that the software came from a specific manufacturer and trusting that it has not been altered in transit is not the same as trusting the company that manufactured the software.
PKI does not establish unique entities for users. The CA binds names to keys, but it does not differentiate between the entities. This uniqueness of the entity, such as a user or a system, must be established beforehand within the organization. For example, you may request John Smith's public key. You may know that particular John Smith, but there are multiple John Smiths within an organization or a community of trust. The uniqueness of John Smith must be established before the request is made. PKI cannot do this.
There are multiple risks associated with PKI, but many entities feel that the largest risk is with key management. If PKI key management is mishandled, the entire PKI system could fail. For example, allowing attackers access to PKI keys is literally like giving away the keys to the server room. All of the implemented security measures would be for nothing.
Warning
Many organizations have not implemented appropriate access controls for their key management system. Lack of controls may allow an internal employee to access the PKI keys as well as decrypt highly sensitive data.
Some may feel that key management itself is a potential risk. Managing a secure environment with multiple keys and multiple entities can be overwhelming, and it's a challenge some organizations are not willing to undertake. Finding the appropriate resources to understand and execute a PKI within an organization is not an easy task. The financial responsibilities associated with PKI implementation are a risk some organizations won't take on. For example, an organization may hire an employee that is not well versed on PKI in order to save on salary expenses. This may mean that the infrastructure will be implemented incorrectly and therefore lack appropriate security. An organization may also choose hardware or software that is inexpensive in order to save on costs, even if the tools do not comply with the organization's standards. Again, this can mean the system will be implemented incorrectly and lack security.
These risks need to be weighed against the potential risk associated with not implementing PKI. How does an organization comply with the standards and regulations of protecting sensitive data if it does not implement PKI? What is the risk associated with customers when their data is stolen from the organization and used to ruin their credit rating or negatively affect other aspects of their life? How do you continue to do business securely if you do not employ the tools to do it correctly?
Risks associated with PKI can come in many forms but, in all cases, the risks must be weighed against the sensitivity of the data. Some organizations must implement PKI because the data they maintain is highly sensitive. Allowing highly sensitive data to get into the wrong hands can be detrimental to an organization, and to the people, companies, and nations the users of PKI are trying to protect.
SSL encryption uses cryptographic techniques to ensure communications between two points or two parties is authenticated and secure. Many organizations use SSL for secure communications including Internet applications and virtual private networks (VPNs). When remote access employees need to access specific tools over the Internet, SSL may be used to secure the transmission of data both through Internet applications and VPNs. Additional information regarding this message transmission was provided in Chapter 11.
Cryptography can be used for encrypting data at rest and data in motion for various business requirements. Examples of cryptography for businesses purposes are:
Encrypting hard drives as a preventive measure in case a laptop or other mobile device is stolen. An organization may choose to encrypt the hard drive to ensure that if the hard drive is removed, the data cannot be read. The organization may choose to require a password during bootup as well. This ensures that the data cannot be read without authenticating the user of the device.
Encrypting removable devices such as universal serial bus (USB) drives. To remove data or read data that is located on a removable drive requires authentication from the owner of the USB drive.
Encrypting instant messaging communication that occurs with users inside or outside of the network. This ensures that any information that is shared via this mode of communication cannot be read by an attacker.
Encrypting file transfers within and outside of the network. This protection secures the data when transmitting outside of the network. It will also provide an extra layer of security even if the network is considered secure.
Encrypting highly sensitive data such as customer data, credit card information, Social Security numbers, or any data that can cause harm when in the wrong hands.
Multiple standards were discussed in Chapter 11, such as Payment Card Industry Data Security Standard (PCI DSS), which requires the protection of consumer's credit card data. One of the PCI DSS requirements is to encrypt the data or file share that the information resides on.
Cryptography is used in businesses for securing e-mail, SSL, and Internet Protocol Security (IPSec). One example of securing e-mail is Secure/Multipurpose Internet Mail Extensions (S/MIME), a standard for encrypting and digitally signing e-mail. S/MIME also provides secure data transmissions by encrypting e-mails and their attachments. MIME is the official standard used to define how the body of an e-mail is structured. The MIME format allows e-mail to contain attachments via MIME-compliant mail systems. These attachments can be audio or video clips, enhanced texts, graphics, and so on. MIME provides no security and therefore S/MIME was proposed.
Note
Encrypting an e-mail protects data as it travels between the sender and the receiver.
The use of S/MIME is illustrated in the following example, in which Alice is preparing an e-mail for Bob. Alice wants to encrypt and digitally sign the e-mail, so she performs the following steps:
Generates a one-time secret key (session key)—Alice generates a secret key for one-time use. This key can also be referred to as a "session key."
Encrypts e-mail with session key—Alice uses the session key to encrypt the e-mail that she intends to send to Bob.
Encrypts session key with receiver's public key—Alice encrypts the session key with Bob's public key.
Signs with sender's private key—Alice digitally signs the e-mail and sends the e-mail package to Bob.
Verifies the signed message digests—Bob receives Alice's e-mail and decrypts the encrypted session key with his private key. He uses the session key to decrypt Alice's encrypted e-mail.
Figure 13-10 shows the commands for signing and/or encrypting e-mails before they are transmitted, using Microsoft Outlook 2007. The valid and appropriate certificates must be loaded into the e-mail client before these actions can occur.
Distribution of keys within an organization is a vital part of key management. You need to ensure the keys are safe and distributed securely. Some organizations choose to outsource these services. The risk associated with not employing the correct resources or not implementing the correct system controls is sometimes left to providers who specialize in the technology. However, outsourcing is not always a good option because of the expense involved, especially if there are many systems, communication paths, or files that need to be encrypted within an organization.
Note
An organization may choose to outsource key management based purely on cost. However, outsourcing key management can have a greater financial impact if it is not done correctly, whether in-house or outsourced.
Determining whether key management should be done in-house or outsourced requires much consideration. There is a large amount of risk associated with key management in terms of security, quality and availability of resources, cost, and other factors. Some considerations regarding in-house versus outsourced key management are:
Total cost associated with IT resources and knowledge. Can an organization afford to manage the infrastructure themselves? Will they have the appropriate resources available in their area to hire and can they afford this resource? Is an organization willing to take on this risk, and can they afford to continually train personnel and manage development as the organization grows?
Managing the keys in-house requires an organization to manage the service level agreements with various business units. Can in-house management ensure the system will be running and functioning correctly 24×7? If disaster occurs, does an organization have the appropriate means to recover in-house?
Can an organization trust an outsourced key management provider? Does this provider have the appropriate resources on-site? Has the provider done necessary background checks on its employees? How can an organization be sure the provider's employees will not provide unauthorized access to resources at the provider's facility?
What level of support can the outsourced entity provide? Can it grow with the organization? Can outsourcer provide appropriate help desk support? Is the outsourcer willing to work with the organization in all situations?
Choosing the appropriate resources from in-house or outsourced key management services is a risky process. Some organizations are uncomfortable with managing such a vital part of security in their own infrastructure. Some feel that leaving this responsibility to providers who know the technology and specialize in its capabilities is more beneficial to them no matter what the cost. Others may feel the opposite and decide that leaving such a high security measure in someone else's hands is not worth the risk. Both options are correct for various types of businesses. The process should be carefully planned because changing direction after initial implementation can cause problems.
Certificate authorities were briefly discussed earlier in the chapter. This section provides more detail about CAs and helps you decide whether to manage certificates in-house or outsource the task to a third party.
Every digital certification implementation is done through a root CA. Each root CA has a digital certificate that is issued by a root CA and to a root CA. A root CA becomes both an issuer and a receiver. This process is called a self-signed digital certificate. This self-signed digital certificate is the root certificate to all certificate implementations. The certificate PKI software or hardware looks for the self-signed certificate and extracts the public key. It is assumed that the certificate and the public key can be trusted. A root CA distributes its public key in a self-signed certificate to Internet browsers or public Internet sites. In theory, all Internet browsers are shipped with a self-signed certificate. A self-signed certificate provides data integrity. An example of a self-signed certificate from VeriSign Trust Network that shipped with the Microsoft Internet Explorer browser is shown in Figure 13-11.
A root CA signs every certificate. In the case of Alice and Bob, Alice can only verify Bob's certificate with the root CA's public key. Once Alice has verified Bob's certificate, she can now trust it. Public key's can only be trusted if they were obtained from a certificate that was granted and issued by a trusted root CA.
Subordinate CAs can be established for more specific needs. For example, a subordinate CA may be implemented specifically for visitors, which would require a separate authentication and registration process. Using this process builds a trusted CA network. If a root CA's private key was compromised, all certificates issued by the root CA and subsequent CAs would need to be revoked and reissued.
A CA in a PKI system has many functions. These individual functions are:
Policy authority—Responsible for establishing, distributing, maintaining, promoting, and enforcing all of the policies of the individual functions. The policy authority is responsible for the policies associated with the content and usage of the certificates, the registration process for certificates, certification revocation, and managing the root and subsequent CAs.
Certificate manufacturer—Generates and manages the digital certificate asymmetric key pairs. The certificate manufacturer may distribute the root public key and sign the certificates. Notification of certificate generation is provided by the certificate manufacturer.
Certificate issuer—Distributes the certificates that are generated by the certificate manufacturer. The certificate issuer provides a way for subscribers to grant and revoke certificates and manage the certificate revocation list.
Revocation manufacturer—Generates and maintains the revocation of the asymmetric key pairs. Notification of the certificate revocation is provided by the revocation manufacturer.
Registration authority—Provides a mechanism for requesting a digital certificate.
Authentication service—Validates the subscriber's credentials for the registration authority prior to the request for the digital certificate.
Repository—Stores and distributes all public key certificates.
All of these functions work as individual and necessary components of PKI system.
Outsourcing a CA may be advantageous to an organization for various reasons. The organization might choose a provider that creates a dedicated CA for the organization's use or might choose to use a shared service from a major CA. Some considerations include:
Communication with suppliers, customers, and business partners is seamless. Companies may not want to worry about the security implications of having multiple entities accessing the CA. What controls are needed, what configurations need to occur, and how do the systems stay updated without impacting the suppliers, customers, business partners, and their own internal users?
Organizations may be geographically dispersed, and it would be more advantageous to have multiple CAs available at these various locations. Organizations may not have the capabilities or resources to staff at the various sites and therefore outsourcing this capability would be highly advantageous.
Organizations do not want to take on the costs associated with managing a CA on-site. This includes the personnel needed to manage the infrastructure as well as the hardware, software, and data center costs.
Much like the risks associated with outsourcing key management, outsourcing a certificate authority is something that should be carefully considered. There are many concerns associated with implementing a security element at a site that you do not own and have it managed by people that do not report to you.
Risks associated with outsourcing CA capabilities are:
The security placed around individual CAs. Is access granted to any employee or are there strict constraints around it? How does an organization know that it can trust a person it does not employ? Are appropriate controls in place at the provider's site, and how does an organization ensure the provider always complies with these controls?
An organization may want to control its own CA because of the higher security requirements. This is not possible when outsourcing a CA. Many organizations with high security requirements are more apt to manage the CA locally where they have more control versus risking a security breach if the CA is managed through a vendor off-site. An organization may need specific certificates with unique fields; therefore, keeping the CA in-house is more beneficial. Allowing another company to manage these highly specific certificates may not be advantageous.
There are multiple risks and issues associated with outsourcing a CA for a PKI system, and all aspects should be covered to ensure an organization is making the right decisions around this infrastructure.
Implementing PKI for use within an organization requires much thought and planning. In order to determine how the capabilities will be used, it is important to understand why you need PKI in the first place and the impact it will have on the organization. The best practices associated with using PKI within a large organization can be determined by answering the following questions:
What are the business drivers for using PKI within the organization? Are you implementing it for e-business? Are you requiring it for integrity, confidentiality, authentication, or non-repudiation? What is the problem that the enterprise or organization is trying to solve?
What applications will be using PKI? Is it being used for secure e-mail, communications, or transactions?
What does the PKI architecture look like and how will it be used? Do all users require the same values and policies or will they need to be managed separately? What encryption algorithms and key lengths will be used in the certificates? Will certificates be used for digital signing and encryption?
What impact will this implementation have on the users, customers, and business partners? How will the users be educated on the technology, and how and when should it be used? Who will develop the necessary policies that impact the users, and how will they be trained?
Where will the infrastructure reside? Will various components be outsourced, or will they all be located in-house? Who will support the infrastructure, and what are expectations around support and disaster recovery?
Can the current organizational infrastructure support the technology? Is the network bandwidth acceptable?
What databases will be used for PKI? Will existing databases be used to streamline enrollment? Will revoked and expired certificates be left in the database? Will a certificate repository be integrated with user account management?
What are the legal and policy considerations for the CA? How will certificates be renewed? What are the procedures associated with requesting and revoking certificates? Are the policies documented?
What are the trust relationships and how are they established? What trust model will the PKI use? Do the products support this model? How will you distribute the trusted roots signed certificates to the PKI users?
How will PKI be deployed? Who are the vendors and how will they support you? How will you install the systems? Who will be trained on the systems? How will you test the system? How will you put the system into production?
Who will have access to the systems and how will this access be monitored? How will the organization grow with the systems and the resources that are provided?
Understanding the components associated with the entire implementation, infrastructure, and deployment, will provide a successful PKI within a large enterprise or organization.
Understanding the benefits and mistakes made by large organizations that have used PKI will be beneficial to you when implementing a successful PKI. Let's review a few ways PKI is currently used as well as some examples of how they can fail.
Perot Systems implemented PKI for enhancing authentication for remote access. Perot Systems soon found that PKI could be used to extend authentication to applications in order to enable e-mail encryption for confidentiality, digital certificates for non-repudiation, and e-forms to eliminate paperwork and expedite processing.
Perot Systems used PKI to authenticate users and devices as part of the VPN network for server-to-server virtual private networking, intranet, and extranet, and client-to-server virtual private networking for remote access employees. Perot Systems PKI was also used with other directories and network resources to enable a greater level of identification for users and network devices.
Multiple lessons were learned as a part of the PKI rollout for Perot Systems, which included:
Select vendors that are industry leading and recognized.
Set clear expectations for management and end users.
Make sure PKI is maintainable.
Ensure ease of rollout and use, supportability, and leveragability of resources.
The United States Patent and Trademark Office (USPTO) manages thousands of patent and trademark requests annually. The USPTO wants to know whom it is dealing with online and wants to provide secure communications. To provide this capability, USPTO chose to implement PKI. USPTO needed to:
Implement confidentiality for information exchange.
Ensure the integrity of the patent application.
Authenticate whom USPTO is dealing with electronically.
USPTO implemented PKI to address all internal and external requirements for security, and non-repudiation, authentication, and integrity for its e-commerce and electronic workplace initiatives. Implementing the PKI system helped build a trusted environment to successfully implement e-commerce. USPTO considered but rejected a password and PIN-based system due to the vulnerabilities of the system. The resources and cost-of-user support to reset forgotten passwords was not a cost that they could afford.
PKI provided the basis for implementing secure e-commerce patent applications and allowed USPTO to move from a paper-based system to an electronic one. The PKI system supported secure and authenticated communications and commerce with USPTO communities, attorneys, agents, international business partners, employees, contractors, and others that the USPTO does business with. All of these entities require a guarantee of authenticity and confidentiality, and PKI provided that.
USPTO also implemented PKI for integration with its public key technology. This provided a single, scalable security infrastructure to support internal and external applications regardless of the risk level. The implementation provided security and authentication for a range of business applications as opposed to the separate security solutions that were previously used.
Achieving a single solution for the various needs that the USPTO required was the benefit that USPTO saw in PKI. The agency realized that the capabilities achieved with PKI provided a solution that would reduce costs and provide the necessary security its customers and employees expected.
As much as it is important to understand how large organizations solve business challenges, it is important to understand how protection can be put in place but not secured. The following are several examples of security breaches associated with PKI and encryption.
In 2001, two digital certificates were issued to a virus writer who was posing as a Microsoft employee. VeriSign issued these certificates in Microsoft's name. These certificates were necessary for consumers who downloaded software that they thought was created by Microsoft. Instead, the software was designed to deploy a virus onto systems on which it was installed. According to Microsoft, the certificates could have been used to sign programs, Microsoft Office macros, and other executable content.
VeriSign did not provide information as to how it validated the virus writer after receiving the request for the certificates. The company did state that human error was the cause of issuing the certificates incorrectly. Once VeriSign realized that the certificates should not have been issued, the company revoked the certificates. However, VeriSign did not have a way to determine who had downloaded the fraudulent software.
Microsoft released a bulletin to its users informing them when the "security warning" screen appears regarding details of the signed software, they needed to click the Microsoft Corporation hyperlink to see if the certificate's valid date is January 29, 2001, or January 30, 2001. If one of these dates matched, the software should be considered fraudulent and the software should not be downloaded.
This example shows how the PKI process failed because the CA issued a certificate without the appropriate verification. Although this is not a normal process and was caught immediately, it shows that any weakness in the system can provide disastrous consequences.
In this chapter, we discussed symmetric and asymmetric encryption algorithms and how they are used with a public key infrastructure. We discussed the risks associated with maintaining key management and certificate authorities in-house or outsourcing it. We reviewed the security services that are provided through the various PKI functions and how each of them functions individually. Understanding these concepts will assist you in understanding why this technology is needed and how its use has expanded over time.
Authentication
Certificate authority (CA)
Certificate revocation list (CRL)
Cloud services
Confidentiality
Cryptosystem
Diffie-Hellman key exchange
Elliptic Curve Cryptosystem (ECC)
Encryption
Integrity
Keyspace
Non-repudiation
Public key infrastructure (PKI)
Registration authority (RA)
RSA asymmetric encryption algorithm
PKI is also known as public key encryption.
True
False
Which of the following is an encryption key size length commonly used with public key algorithms?
12 7
255
1,023
2,048
Which of the following are examples of symmetric algorithms? (Select two.)
RSA
3DES
AES
Diffie-Hellman
Which of the following are examples of asymmetric algorithms? (Select two.)
RSA
3DES
AES
Diffie- Hellman
Asymmetric encryption is faster than symmetric encryption.
True
False
A symmetric encryption algorithm provides which security services? (Select three.)
Confidentiality
Identity
Authentication
Authorization
Non-repudiation
The RSA key length is_________.
Which of the following is the standard for certificates?
X.510
Certificate authority
X.509
Certificate validation
Which of the following terms is the range of values that construct a cryptosystem key?
Key length
Key values
Keyspace
Key construction
Digital signatures provide which of the following? (Select two.)
Confidentiality
Integrity
Authentication
Authorization
Non-repudiation