A public key infrastructure is important because it provides secure mechanisms for business and eCommerce transactions. It provides a community of trust. Through this community of trust, people are able to browse the web more securely, send secure emails, and download safe software. PKI does not solve all security issues, and it does not make all software safe or ensure that websites 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 multilayer security system within an organization.
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 and 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 for it to be successful and secure.
Components of a PKI are:
Essentially, a PKI provides services that protect confidentiality, integrity, authentication, and nonrepudiation 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 cleartext (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 need to be decrypted, resulting in the original cleartext. FIGURE 11-1 shows this process.
You can use access controls to allow or deny access to data on systems and networks. But how do you protect those data while they are being transferred from one system to another or while they are 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, the keys, and the software and protocols. The algorithm determines how the encryption and decryption will take place. Examples of symmetric encryption algorithms are 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 of the information. The ciphertext is secure only 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 constructs 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 number 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 that the key is secure. The specific key length considered secure will vary depending upon the algorithm being used. For example, a 256-bit key used with one algorithm may actually be more secure than a 1024-bit key used with a different algorithm. However, longer keys are always more secure when used with the same algorithm.
Symmetric encryption. 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 allow only the users who have the secret key to read the data. The strengths and weaknesses associated with symmetric key systems are:
FIGURE 11-2 shows how a shared secret key is used in symmetric encryption. Compare this with Figure 11-1 and notice that the same key is used as the encryption key and the decryption key in this case.
Asymmetric encryption. 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 be known or used only 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 email addresses. The public and private keys are mathematically related so that anything encrypted with one can only be decrypted with the other. In a strong cryptosystem, someone who has the public key cannot 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.
Although you can encrypt data with either key, remember that you can obtain confidentiality only 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 done only for purposes of authentication or nonrepudiation, such as in digital signatures.
Asymmetric cryptography can also provide authentication when the sender encrypts data with his or her own private key. After the receiver decrypts the message with the sender’s public key, the receiver knows that it could only have come from the sender’s private key. Note from FIGURES 11-3 and 11-4 that a public key can be used for both encryption and decryption. If data are encrypted with a public key, they can only be decrypted with the private key. If data are encrypted with the private key, they can be decrypted only 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:
GROUP SIZE (n) | SYMMETRIC KEYS NEEDED | ASYMMETRIC KEYS NEEDED |
---|---|---|
2 | 2 | 4 |
3 | 3 | 6 |
5 | 10 | 10 |
10 | 45 | 20 |
100 | 4,950 | 200 |
1,000 | 499,950 | 2,000 |
10,000 | 49,995,000 | 20,000 |
100,000 | 4,999,950,000 | 200,000 |
Businesses require cryptography for multiple uses within an organization. Common examples of the use of cryptography include protecting 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 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 communications against attackers. Ensuring trusted communications between entities is vital for organizations to ensure their data are secure and seen or received only from trusted users.
With the implementation of cloud services, businesses want to ensure that data kept in the cloud are 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 they would on-site. Using 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 that security is 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.
Government agencies must also ensure that the cryptographic algorithms they choose are supported by the federal government and endorsed for the types of information they need to protect. Agencies should consult “Security Requirements for Cryptographic Modules,” published as Federal Information Processing Standard (FIPS) 140. The current version of FIPS 140, FIPS 140-3, went into effect in September of 2019.
Digital certificates are used by individual users, servers, and devices to provide unknown third parties with a known secure copy of their public encryption key. This is especially true with the rise of the Internet of Things (IoT). Digital certificates may be used for a variety of purposes, including email, web servers, and other forms of encrypted communication. Certificate Authorities (CAs) issue digital certificates after verifying the identity of the end user and the end user can then use that certificate to share its public key with others. CAs use the X.509 digital certificate standard to create certificates that contain the following fields:
FIGURE 11-5 shows an example of a digital certificate.
When digital certificates are stored on a system, they come in the form of files. These files have a variety of different formats, and many systems support some, but not all, of these formats. Make sure that your file format is acceptable for the specific applications you have in mind. Common digital certificate file formats include:
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.
Depending on the degree of verification performed by the RA, the CA may issue certificates with different validation levels. The three certificate validation levels are:
Key management ensures the security of the cryptographic keys through each key’s life cycle. Components of key management are:
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:
Symmetric and asymmetric encryption algorithms are varied in many ways. You just learned about a few ways they can be 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.
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.
The Diffie-Hellman algorithm is more susceptible to man-in-the-middle attacks because no authentication occurs when the public keys are sent. In other words, how does Bob know that he is actually communicating with Alice and not someone else who initiated the Diffie-Hellman process on her behalf? If an attacker intercepted the public keys and instead sent his own, the symmetric key would be created using the attacker’s public key. The attacker would be the only one who could read the messages.
Mathematically, Diffie-Hellman looks like this:
The names Alice and Bob are commonly used in encryption examples. Alice is normally the sender of a message and Bob is normally the recipient.
The RSA asymmetric encryption algorithm was developed to prevent 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 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 shorter key. When a shorter 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 11-2.
Attribute | Asymmetric Algorithms | Symmetric Algorithms |
---|---|---|
Keys | Public key is available to all; private key is kept secret to the owner and never shared | Sender and recipient share a secret key. |
Key length required | Longer | Shorter |
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 | Faster |
Security services provided | Confidentiality, integrity, authentication, and nonrepudiation | Confidentiality, integrity, and authentication |
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 a new user wants to communicate with the subject of the certificate, the new user can verify that the certificate bears the valid signature of a trusted CA.
CAs can be internal to an organization, which allows the organization to have complete control over the distribution and life of the certificate. In this case, the organization is issuing self-signed certificates. 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 11-6.
You’ll learn more about CAs later in this chapter.
The following example illustrates a CA used in a PKI system:
This process is shown in FIGURE 11-7.
Certificate authorities may revoke digital certificates that have been compromised or are otherwise no longer valid. To do this, they may include the certificate on the CA’s Certificate Revocation List (CRL). The CRL is simply a listing of invalid certificates that software is expected to consult before accepting a digital certificate. Due to some limitations in the CRL approach, it is being replaced with the Online Certificate Status Protocol (OCSP), which is a method for live, interactive verification of a certificate’s status.
Certificate authorities document their practices for issuing and maintaining digital certificates in a formal statement known as the Certificate Practice Statement (CPS). This statement provides details on the business processes used by the CA to verify the identity of certificate owners prior to issuing the certificate, revoking digital certificates, renewing expired certificates, and other certificate practices.