CIST 1601 Information Security Fundamentals

CIST 1601 Information Security Fundamentals Chapter 9 Cryptography Implementation Collected and Compiled By JD Willard MCSE, MCSA, Network+, Microsoft IT Academy Administrator Computer Information Systems Technology Albany Technical College

Using Public Key Infrastructure A public key infrastructure is a vast collection of varying technologies and policies for the creation and use of digital certificates. PKI is a widely implemented cryptographic system. Corporations, government, and individuals use PKI extensively. The need for universal systems to support e-commerce, secure transactions, and information privacy is one aspect of the issues being addressed with PKI. PKI is a two-key asymmetric system with four key components: Certificate Authority (CA) Registration Authority (RA) RSA Digital certificates Messages are encrypted with a public key and decrypted with a private key. The main goal of PKI is to define an infrastructure that should work across multiple vendors, systems, and networks. Implementations of PKI are dependent on the perspective of the software manufacturers that implement it. This has been one of the major difficulties with PKI: Each vendor can interpret the documents about this infrastructure and implement it however they choose. For this reason, many of the existing PKI implementations aren’t compatible with each other.

Certificate Authorities (5:37) Implementing Certificate Authorities (3:16) Using a Certificate Authority A certificate authority (CA) is an organization responsible for maintaining certificates in the public key infrastructure (PKI) environment. CAs are trusted entities and an important concept within PKI. CAs can be either private or public. Many OS providers allow their systems to be configured as CAs. These CAs can be used to generate internal certificates used within a business. The CA’s job is to issue certificates, as well as to verify the holder of a digital certificate, and ensure that the holder of the certificate is who they claim to be. This includes: Issuing certificates Revoking certificates Distributing certificates A certificate is really nothing more than a mechanism that associates the public key with an individual. A certificate contains a great deal of information about the user. A root certificate authority differs from subordinate CAs in that the root CA is taken offline to reduce the risk of key compromise, and the root CA should be made available only to create and revoke certificates for subordinate CAs. If the root CA is compromised, then the entire architecture is compromised. If a subordinate CA is compromised, however, the root CA can revoke the subordinate CA. In a certificate trust model, everybody’s certificate is issued by a third party called certificate authority (CA). If one trusts the CA, he automatically trusts the certificates that CA issues.

Working with Registration Authorities andLocal Registration Authorities An RA offloading work from a CA A registration authority (RA) can offload some of the work from a CA. RAs don’t issue certificates, but they can serve as intermediaries in the process by authenticating requests. An RA provides authentication to the CA as to the validity of a client’s certificate request; In addition, the RA serves as an aggregator of information. It can: Distribute keys Accept registrations for the CA Validate identities. The RA doesn’t issue certificates; that responsibility remains with the CA. A local registration authority (LRA) can establish an applicant’s identity and verify that the applicant for a certificate is valid. The LRA sends verification to the CA that issues the certificate. The LRA verifying identity for the CA

Certificates Certificates are another form of authentication. A server or certificate authority (CA) can issue a certificate that will be accepted by the challenging system. Certificates can be either physical access devices, such as smart cards, or electronic certificates that are used as part of the logon process. A Certificate Practice Statement (CPS) outlines the rules used for issuing and managing certificates. A Certification Revocation List (CRL) lists the revocation that must be addressed (often due to expiration) in order to stay current.

Certificates A certificate being issued after identification has been verified.

Digital Certificates (3:04) Implementing Digital Certificates (2:57) A certificate illustrating some of the information stored Implementing Certificates Certificates provide the primary method of identifying that a given user is valid. Certificates can also be used to store authorization information. Key certification is a system that enables the receivers of a key to certify the identity of a key sender. Encryption systems typically provide password protection to protect private keys. X.509 The most popular certificate used is the X.509 version 3. Adopting a standard certificate format is important for systems to be assured interoperability in a certificate-oriented environment. Always remember that the purpose of the certificate is to basically bind the public key to the user’s identity. When authenticating, certificates can be used to authenticate only the client (single sided) or both parties (dual sided), the client and server. Notice that the certificate contains identifiers of two different algorithms used in the process. In this case, the signature algorithm is Md2RSA, and the digital signature algorithm is sha1. This certificate also has a unique serial number issued by the CA.

Implementing Certificates The certificate life cycle is typically based on two documents: the certificate policy and the certificate practice statement (CPS). Certificate policies affect how a certificate is issued and how it is used. A certificate policy indicates specific uses applied to a digital certificate, as well as other technical details. Thus, the certificate policy provides the rules that indicate the purpose and use of an assigned digital certificate. A CA can potentially issue a number of different types of certificates: One for e-mail One for e-commerce One for financial transactions The policy might indicate that it is not to be used for signing contracts or for purchasing equipment. A CA would have policies regarding the interoperability or certification of another CA site; the process of requiring interoperability is called cross certification. A certificate practice statement (CPS) is a statement that the CA uses to issue certificates and implement the policies of the CA. This is a detailed document that is used to enforce policy at the CA. These statements should discuss how certificates are issued, what measures are taken to protect certificates, and the rules that CA users must follow in order to maintain their certificate eligibility. These policies should be readily available to CA users.

Understanding Certificate Revocation Certificate revocation is the process of revoking a certificate before it expires. A CRL is created and distributed to all CAs to revoke a certificate or key. Revoking a certificate is just not enough. The community that trusts these certificates must be notified that the certificates are no longer valid. This is accomplished via a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP). The CRL is published on a regular basis, but it isn’t current once it’s published. A CRL contains a list of serial numbers for digital certificates that have not expired, but that a CA has specified to be invalid. Typically, the serial number of a digital certificate is placed in a CRL because the digital certificate has been compromised in some way. A certificate is revoked either when the information contained in the certificate is supposedly compromised or when the certificate expires. The revocation request can be initiated by the following entities: The certificate holder The CA itself Another CA that issued certificates An associated RA During the process of revocation, the requesting entity should be duly authenticated as with a regular transaction. The procedure used to authenticate the entity during revocation remains the same as that used to issue the certificate. The revocation request carries a digital signature with a valid digital certificate. The CA that entertains the revocation request placed by an entity decides the amount of time necessary to process the request. This is referred to as the revocation request grace period.

Understanding Certificate Revocation Online Certificate Status Protocol (OCSP) is the mechanism used to immediately verify whether a certificate is valid. OCSP solves the latency problem: If the recipient or relying party uses OCSP for verification, the answer is available immediately. Certificate suspension occurs when a certificate is under investigation to determine if it should be revoked. This mechanism allows a certificate to stay in place, but it is not valid for any type of use during the suspension. Like the status checking that occurs with revoked certificates, users and systems are notified of suspended certificates in the same way. The primary difference is that new credentials will not need to be retrieved; it is only necessary to be notified that current credentials have had a change in status and are temporarily not valid for use.

Trust Models (3:41) Implementing Trust Models In the single certificate authority (CA) model, only one CA exists to issue and revoke certificates. Although this model may be beneficial to smaller organizations because of its administrative simplicity, it has the potential to present problems. If the private key of the CA becomes compromised, all the issued certificates from that CA would then be invalid. Cross certification is primarily used to establish trust between different PKIs and build an overall PKI hierarchy. The process implies the establishment of a trust relationship between two CAs through the signing of another CA’s public key in a certificate referred to as a cross certificate. Cross certification allows users to build a trust relationship between different certification hierarchies, when users are required to communicate, and might require authentication for legitimate connections. CAs are organized in a trust hierarchy or trust mesh. In a hierarchy model, a root CA is at the top of a CA trust hierarchy and contains a root certificate, which is used to sign certificates for CAs in the level immediately below the root CA. In a mesh model, CAs may certify other CAs, provided no naming constraints are applied.

Hierarchical Trust Models A Hierarchical trust model, also known as a tree, (hierarchy of certificate servers) is the most common model. In a hierarchical trust model, the intermediate CAs only trust information that is provided from the root CA. Additionally, the root CA will also trust intermediate CAs that are in their hierarchy. This might be the most common implementation in a large organization that wants to extend its certificate processing capabilities. Hierarchical models allow tight control over certificate-based activities at all levels of the hierarchical tree. In this situation, the intermediate CAs trust only the CAs directly above them or below them.

Bridge Trust Models In a bridge trust model, a peer-to-peer relationship exists between the root CAs. Each of the root CAs can communicate with each other, allowing cross certification. It is possible to have a single CA, known as the bridge CA, be the central point of trust. This allows a certification process to be established between organizations or departments. Each of the intermediate CAs trusts only the CAs above and below it, but the CA structure can now be expanded without creating additional layers of CAs. Additional flexibility and interoperability between organizations are the primary advantages of a bridge model. Lack of trustworthiness of the root CAs can be a major disadvantage. If one of the root CAs doesn’t maintain tight internal security an illegitimate certificate could become available to all the users in the bridge structure and its subordinate or intermediate CAs. This model may be useful if you’re dealing with a large, geographically dispersed organization or you have two organizations that are working together. The intermediate CAs communicate only with their respective root CA. All cross certification is handled between the two root CA systems.

Mesh Trust Models An alternative to the hierarchical model is the mesh trust model, often referred to as the cross-certification model or Web of Trust. The mesh model expands the concepts of the bridge model by supporting multiple paths and multiple root CAs. Certificate authorities are considered peers to one another. It also has the ability to cross certify with the other root CAs in the mesh. This may also be referred to as a web structure. This structure may be useful in a situation where several organizations must cross-certify certificates. The advantage is that you have more flexibility when you configure the CA structures. The major disadvantage of a mesh is that each root CA must be trustworthy in order to maintain security. Each of the root CAs can cross-certify with the other root CAs in the mesh.

Hybrid Trust Model A hybridtrust model can use the capabilities of any or all of the structures that have been discussed in the previous sections. You can be extremely flexible when you build a hybrid trust structure. The major difficulty with hybrid models is that they can become complicated and confusing. A user can unintentionally acquire trusts that they shouldn’t have obtained. In addition, relationships between CAs can continue long past their usefulness, even after the parent organizations have terminated their relationships. Notice the single intermediate CA server on the right side is the only server that is known by the CA below it. The subordinates of the middle-left CA are linked to the two CAs on its sides. These two CAs don’t know about the other CAs, because they are linked only to the CA that provides them a connection. The two intermediate servers in the middle of the illustration and their subordinates trust each other; they don’t trust others that aren’t in the link.

Preparing for Cryptographic Attacks Specific attacks on cryptographic systems can be divided into three types: Attacking the key Key attacks are typically launched to discover the value of a key by attacking the key directly. The keys can be passwords, encrypted messages, or other key-based encryption information. An attacker might try to apply a series of words, commonly used passwords, and other randomly selected combinations to crack a password. The anticipated amount of time it takes to break a password depends on the length of the password and the characters used in the password. Making keys longer and more complicated tends to make key attacks more difficult. Attacking the algorithm The programming instructions and algorithms used to encrypt information are as much at risk as the keys. Many algorithms have well-publicized back doors. If a weakness in the programming or model used to develop an algorithm is discovered, a significant security exposure may exist. Intercepting the transmission The process of intercepting a transmission may, over time, allow attackers to inadvertently gain information about the encryption systems used and then use frequency analysis to break an algorithm. Human error is also a problem in security situations, and it’s likely that someone will unintentionally release information that can be used to undermine a security system.

Preparing for Cryptographic Attacks You should also be aware of the following three types of attacks: Birthday attack A birthday attack is an example of an attack targeted at the key. It isn’t an attack on the algorithm itself, just on the results. If your key is hashed, the possibility is that given enough time, another value can be created that will give the same hash value. Birthday attacks are based on the statistical likelihood of a match. As the key length grows, the probability of a match decreases. Weak key attack Weak key attacks are based on the premise that many common passwords are used by lots of people. If the key length is short, the resulting hash value will be easier to guess. Make sure your users use passwords and encryption keys that are hard to guess. The longer and more complicated a password is, the more difficult it is to successfully launch a weak key attack against it. Enforcing strict password guidelines can minimize this vulnerability. Mathematical attack Mathematical attacks can be focused on the encryption algorithm itself, the key mechanism, or any potential area of weakness in the algorithm. These attacks use mathematical modeling and statistical analysis to determine how the system operates. These types of attacks depend on intercepting large amounts of data and methodically attempting to decrypt the messages using one of the methods previously described.

Public Key Infrastructure (3:33) Understanding Key Management and the Key Life Cycle Key management includes the following stages/areas: Centralized versus decentralized key generation Key storage and distribution Key escrow Key expiration Key revocation Key suspension Key recovery and archival Key renewal Key destruction Key usage The certificate key life cycle refers to those events required to create and preserve, use, and destroy public keys and the digital certificates with which they are associated. The certificate life cycle is typically based on two documents: the certificate policy and the certification practice statement (CPS). Three basic status levels exist in most public key infrastructure (PKI) solutions: Valid, Suspended, and Revoked.

Methods for Key Generation A centralized key-generating facility Key generation (creating the key) is an important first step in the process of working with keys and certificates. Certificates are one of the primary methods used to deliver keys to end entities. Key length and the method used to create the key also affect the security of the system in use. Centralized Key Generation Although the benefit of central control may be seen as an advantage, a centralized system also has other disadvantages: Additional required infrastructure A need to positively authenticate the end entity prior to transmitting the private key Key archival and storage process may be vulnerable to an attack against a single point The need for a secure channel to transmit the private key. Transmitting private keys is a major concern. Private keys are typically transported using out-of-band methods to ensure security.

A distributed key-generating system Methods for Key Generation Decentralized Key Generation In a decentralized key generation system, the end user generates his or her own key pair. One of the primary advantages of using decentralized/distributed key generation is that the key distribution isn’t vulnerable to a single point of failure or attack. Decentralized generation addresses the distribution issue, but it creates a storage and management issue. Split-System Key Generation Many systems, including the PKI system, require the use of a split system. In a split system, the central server generates encryption keys. Digital signature keys are created at the client or in a smart card. In this situation, the loss of any single key-generating system doesn’t disrupt the entire network. The RA in the figure refers to a registration authority, and the CA refers to a certificate authority.

Storing and Distributing Keys Kerberos uses a KDC to store, distribute and maintain cryptographic session keys and secret keys, and keep a list of revoked keys. The master key is used to exchange the session keys. The keys are automatically distributed to the communicating client and the server. The KDC also provides the authentication services for the users. The client requests resource access through the KDC. As a response to the request, the KDC generates a session key that is a combination of the secret keys of the client and the server. The session key is decrypted by both the client and the server to successfully authenticate to each other and to initiate communication. Proper key storage requires that the keys be physically stored in a secure environment. This may include using locked cabinets, hardened servers, and effective physical and administrative controls. Where and how keys are stored affects how they are distributed. Distributing keys is usually accomplished using a Key Distribution Center (KDC), as used in Kerberos, or by using a Key Exchange Algorithm (KEA), as in the case of PKI.

Storing and Distributing Keys The KEA process is slightly different from the KDC process. KEA is used to create a temporary session to exchange key information. This session creates a secret key. The KEA session terminates once the key has been successfully transmitted, and the regular session begins. The KEA process

Key Escrow (2:47) Using Key Escrow A key escrow system stores keys for the purpose of law enforcement access. If a criminal investigation is underway, law enforcement agents, with a search warrant, have the right to access and search records within the scope of the warrant. Key escrow occurs when a CA or other entity maintains a copy of the private key associated with the public key signed by the CA. It allows the CA or escrow agent to have access to all the information that is encrypted using the public key from a user’s certificate, as well as create digital signatures on behalf of the users. Key escrow can also allow access to information in a PKI system if the client’s private key becomes unavailable for some reason. It also enables an organization to overcome the large problem of forgotten passwords. Rather than revoke and reissue now keys, an organization can generate a new certificate using the private key stored in escrow.

Identifying Key Expiration A key expiration date identifies when a key is no longer valid. Normally, a key is date stamped. This means that it becomes unusable after a specified date. A new key or certificate is normally issued before the expiration date. Keys with expiration dates work similarly to credit cards that expire. So long as the certificate holder’s needs or identity information has not changed, the process is relatively simple. After the issuing CA validates the entity’s identity, a new certificate can be generated based on the current public key.

Key Revocation (2:54) Implementing Key Revocation (2:19) Revoking Keys Keys are revoked when they are compromised, the authentication process has malfunctioned, when people are transferred, and when many other security risks occur. Revoking a key keeps it from being misused. A revoked key must be assumed to be invalid or possibly compromised. A component of public key infrastructure (PKI) includes a mechanism for distributing certificate revocation information, called certificate revocation lists (CRLs). A CRL is used when verification of digital certificate takes place to ensure the validity of a digital certificate. Systems such as PKI use a CRL to perform a check on the status of revoked keys. Revocations are permanent. Once a certificate is revoked, it can’t be used again; a new key must be generated and issued.

Suspending Keys Suspending keys is a good practice: It disables a key, making it unusable for a certain period of time. This can prevent the key from being used while someone is gone. The key can be reactivated when that person returns. If an employee were to take a leave of absence, the employee's key could be suspended until they came back to work. This temporary suspension would ensure that the key would not be usable during their absence. A suspension might also occur if a high number of failed authentications or other unusual activities were occurring. Checking the status of suspended keys is accomplished by checking with the certificate server or by using other mechanisms. In a PKI system, a CRL would be checked to determine the status of a certificate.

Key Recovery (3:10) Implementing Key Recovery (2:30) Recovering and Archiving Keys Keyrecovery is the process of restoring a key pair from a backup and recreating a digital certificate using the recovered keys. A key recovery process must be able to recover a previous key. If not recovered, then all the information for which the key was used will be irrecoverably lost. One of the problems with a key-based system is that older information, unless processed with a new key, may become inaccessible. If for example, you have a two-year-old file on your system and it is still encrypted, will you remember which key was used to encrypt it two years ago? If you are like most people, you won't. If you can't decrypt the data, it is useless. To deal with this problem, archiving old keys is essential. Any time a user or key generator creates and issues a key, the key must also be sent to the key archive system. This is most easily done on a server that offers secure storage. Older keys can be stored and retrieved when necessary. Many recovery and archive systems use the M of N Control method of access. Simply stated, in order to access the key server if n number of administrators have the ability to perform a process, m number of those administrators must authenticate for access to occur. M of N control as it relates to PKI refers to the concept of backing up the public and private key across multiple systems. This multiple backup provides a protective measure to ensure that no one individual can re-create his or her key pair from the backup. The key archival system

Renewing Keys Key renewal defines the process of enabling a key for use after its scheduled expiration date. A key would be reissued for a certain time in this situation. This process is called a key rollover. In most cases, the rollover of keys is something that occurs for a given time frame. In general, key renewals are a bad practice and should not be performed except in the direst of situations. The longer a key is used, the more likely it is to be compromised. It is always better to renew keys than to do a key rollover. Many systems provide a way to renew existing keys, rather than a rollover.

Destroying Keys Key destruction is the process of destroying keys that have become invalid. For example, an electronic key can be erased from a smart card. Many symmetrically based encryption systems use a dedicated device to carry the key for the encryption. This key would be physically delivered to the site using the encryption system. Old keys would be recovered and destroyed. If the key pair to be destroyed is used for digital signatures, the private key portion should be destroyed first, to prevent future signing activities with the key. In addition, a digital certificate associated with a key that is no longer valid should be added to the CRL regardless of whether the key is actually destroyed or archived. Whether you’re using physical keys or software-oriented key systems, old keys must be destroyed in a manner that ensures they don’t fall into unauthorized hands.

Identifying Key Usage During the time when the key is not being revoked, suspended, renewed, or destroyed, it is being used. Key usage is simply the use (and management) of public and private keys for encryption. There is nothing additional to know here, thank goodness!

The End

CIST 1601 Information Security Fundamentals