Computer Security Test
- 1. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Public Key Infrastructure (PKI) Chapter 6 © 201 2
- 2. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Objectives • Implement the basics of public key infrastructures. • Describe the roles of certificate authorities and certificate repositories. • Describe the role of registration authorities. • Explain the relationship between trust and certificate verification. • Use digital certificates. • Identify centralized and decentralized infrastructure. • Describe public and in-house certificate authorities. © 201 2
- 3. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Key Terms © 201 2
- 4. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Public Key Infrastructure (PKI) • Manages the sharing of trust using a third party to vouch for the trustworthiness of a claim of ownership over a credential document, called a certificate. • Allows for different types of users and entities to be able to communicate securely and in a predictable manner. • PKI is made up of hardware, applications, policies, services, programming interfaces, cryptographic algorithms, protocols, users, and utilities. • Facilitates the use of public key cryptography, and symmetric keys for digital signatures, data encryption, and integrity. © 201 2
- 5. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Can You Trust That Key? © 201 2
- 6. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Basics of Public Key Infrastructures • PKI environments use entities called registration authorities (RAs) and certificate authorities (CAs). • PKIs work like the DMV. – You prove you who you are to the DMV by bringing the information they require. – If you have met the requirements, you are issued an Identification card. – When people ask you who you are, you show the ID from the DMV. – They should now believe you are who you say you are. • PKI helps prevent a man-in-the-middle attack. © 201 2
- 7. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Digital Certificates and Public Keys © 201 2
- 8. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Certificate Authorities (CA) • CAs are a trusted authority that certifies identities and creates digital certificates. • Digital certificates establish an association between the subject’s identity and a public key. • The private key that is paired with the public key in the certificate and is stored separately. • Certification practices statement (CPS) outlines how identities are verified. • Certificate server is the service that issues certificates. – Constructs the digital certificate and combines the user’s public key with the resulting certificate. – The certificate is digitally signed with the CA’s private key. © 201 2
- 9. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Registration Authorities (RA) • An RA is a PKI component that accepts a request for a digital certificate and performs the steps of registering and authenticating the person requesting the certificate. • The authentication requirements differ depending on the type of certificate being requested. • Most CAs offer a series of classes of certificates with increasing trust by class. • If an application creates a key store that can be accessed by other applications, it will provide a standardized interface, called the application programming interface (API). © 201 2
- 10. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Certificate Classes Class 1 This is for software signing. A software vendor would register for this type of certificate so that it could digitally sign its software. This provides integrity for the software after it is developed and released, and it allows the receiver of the software to verify from where the software actually came. 3 201 2 This is used to verify an individual’s identity through e-mail. A person who receives a Class 1 certificate can use his public/private key pair to digitally sign e-mail and encrypt message contents. 2 © Typical Use This is for a company to set up its own CA, which will allow it to carry out its own identification verification and generate certificates internally.
- 11. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Steps for Obtaining a Digital Certificate © 201 2
- 12. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Application Programming Interface (API) © 201 2
- 13. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Local Registration Authorities (LRA) • Performs the same functions as an RA. • Implemented in companies that have their own internal PKIs and have distributed sites. • Instead of requiring users to communicate with a central RA, each site can have its own LRA. • Reduces the traffic created by several users making requests across wide area network (WAN) lines. © 201 2
- 14. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Certificate Repositories • A centralized directory of public keys and certificates that can be accessed by a subset of individuals. • Usually Lightweight Directory Access Protocol (LDAP)– compliant. • If a person wants to encrypt the first message to the receiver, the sender needs to find the receiver’s public key in a certificate repository. © 201 2
- 15. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Trust and Certificate Verification • Use PKI if you do not automatically trust individuals you do not know. • A third party that is trusted by both the first and second party is needed. • A user will trust a certificate authority and download that CA’s digital certificate and public key. • Certificate authorities you trust can be found in your browser’s list. © 201 2
- 16. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition The Browser’s List of CAs © 201 2
- 17. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Steps for Verifying a Certificate © 201 2
- 18. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Validating a Certificate 1. Compare the CA that digitally signed the certificate to a list of CAs that have already been loaded into the receiver’s computer. 2. Calculate a message digest for the certificate. 3. Use the CA’s public key to decrypt the digital signature and recover what is claimed to be the original message digest embedded within the certificate (validating the digital signature). 4. Compare the two resulting message digest values to ensure the integrity of the certificate. 5. Review the identification information within the certificate, such as the e-mail address. 6. Review the validity dates. 7. Check a revocation list to see if the certificate has been revoked. © 201 2
- 19. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Digital Certificates • A digital certificate binds an individual’s identity to a public key. – Contains all information a receiver needs to be assured of the identity of the public key owner. • The certificates are created and formatted based on the X.509 standard. – International Telecommunication Union (www.itu.int). – It outlines the necessary fields and values of a certificate. – As of this writing, version 3 is the most current © 201 2
- 20. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Fields Within a Digital Certificate © 201 2
- 21. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Certificate Attributes • End-entity certificates are issued by a CA to a specific subject. • CA certificate can be self-signed (in the case of a standalone or root CA), or it can be issued by a superior CA within a hierarchy. – May be necessary when a company has multiple internal CAs • Cross-certification certificate – These are used when independent CAs establish peer-to-peer trust relationships. • Policy certificate – These are used for high security applications to provide centrally controlled policy information to PKI clients. © 201 2
- 22. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition End-Entity and CA Certificates © 201 2
- 23. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Certificate Extensions • Allow for further information to be inserted within the certificate – Can be used to provide more functionality in a PKI implementation – Can be standard or private • Standard certificate extensions are implemented for every PKI implementation. • Private certificate extensions – Defined for specific organizations; allows companies to further define uses for digital certificates to best fit their business needs © 201 2
- 24. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Critical and Noncritical Extensions • Critical extensions – The extension must be understood and processed by the receiver. – If the receiver is not configured to understand a particular extension marked as critical, the certificate cannot be used for its proposed purpose. • Noncritical extensions – The certificate can be used for the intended purpose, even if the receiver does not process the appended extension. © 201 2
- 25. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Certificate Lifecycles • Keys and certificates should have lifetime settings that force the user to register for a new certificate after a certain amount of time. • Determining the proper length of these lifetimes: – Shorter lifetimes limit the ability of attackers to crack them. – Longer lifetimes lower system overhead. – More-sophisticated PKI implementations perform automated and transparent key updates to avoid having users register for new certificates when old ones expire. • Certificate management involves – Registration, certificate and key generation, renewal, and revocation. Additional management functions include CRL distribution, certificate suspension, and key destruction. © 201 2
- 26. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Registration and Generation • Key pair can be generated – Locally, by an application and stored on a local key store on the user’s workstation – Remotely, by a central key-generation server. Keys would then have to be securely transmitted. • Registration – If a key pair is used for encryption, the RA can send a challenge value to the individual. – That person will use the private key to encrypt that value and return it to the RA. – If the RA can successfully decrypt this value with the public key the keys are registered. © 201 2
- 27. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Renewal • The certificate itself has its own lifetime, which can be different from the key pair’s lifetime. – The certificate’s lifetime is specified by the validity dates inserted into the digital certificate. – The certificate cannot be used before the start date, nor after the end date. • Renewal – If the certificate has not been revoked, the original keys and certificate are used to provide authentication for renewal. • New certificate – If the certificate just expired a new certificate can be generated with new validity dates. – If the functionality needs to be expanded or restricted, a new certificate is generated. © 201 2
- 28. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Revocation • A certificate can be revoked when its validity needs to be ended before its actual expiration date is met. • Done when the private key has been compromised or the holder of the certificate is no longer with the organization. • Once revoked, a certificate cannot be reinstated. • The CA provides this type of protection by maintaining a certificate revocation list (CRL): – A list of serial numbers of certificates that have been revoked – Also contains a statement indicating why the individual certificates were revoked and a date when the revocation took place. © 201 2
- 29. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Reason Code Reason 0 1 Unspecified All keys compromised; indicates compromise or suspected compromise 2 CA compromise; used only to revoke CA keys 3 Affiliation changed; indicates a change of affiliation on the certificate 4 Superseded; the certificate has been replaced by a more current one 5 Cessation; the certificate is no longer needed, but no reason exists to suspect it has been compromised 6 Certificate hold; indicates the certificate will not be issued at this point in time 7 Remove from CRL; used with delta CRL to indicate a CRL entry should be removed © 201 2
- 30. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition The CA Digitally Signs the CRL © 201 2
- 31. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition CRL Distribution • CRLs can be requested by individuals or pushed down periodically. • CRLs can grow substantially in size. – The smaller the better to reduce load on resources. – Updates may be only changes to CRL. • A certificate might have an extension that points the validating user to the necessary CRL distribution point. © 201 2
- 32. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition CRL Distribution (continued) • Online service – User can communicate with an online service that will query the necessary CRLs available within the environment. • Online Certificate Status Protocol (OCSP) – Protocol used for online revocation services © 201 2
- 33. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Suspension • Instead of being revoked, a certificate can be suspended, meaning it is temporarily put on hold. • Useful if the holder of the certificate will not be using it for an extended period of time. • The CRL would list the certificate as being in a “hold” state. © 201 2
- 34. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Key Destruction • Key pairs and certificates have set lifetimes. • It is important that the certificates and keys are properly destroyed wherever the keys are stored (on users’ workstations, centralized key servers, USB token devices, smart cards, and so on). • Prevents potential malicious activity: – An attacker might use the key to digitally sign or encrypt a message with the hopes of tricking someone else about his identity. – Might try to brute force attack the cryptosystem. © 201 2
- 35. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Centralized and Decentralized Infrastructures • Centralized infrastructure - Keys are generated and stored on a central server, and keys are transmitted to individual systems as needed. – Workstations may not have processing power to produce keys – Easier backups and recovery procedures • Decentralized infrastructure - Software on individual computers generates and stores cryptographic keys. – Avoids the difficulty of secure key distribution – Avoids single point of failure – Better to generate end-user keys on a local machine to eliminate doubt about who did the work and “owns” the keys © 201 2
- 36. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Hardware Storage Devices • PKIs can be constructed in software without special cryptographic hardware. – Suitable for most environments • But software can be vulnerable to viruses, hackers, and hacking. – If a person obtained a root CA private key, she could digitally sign any certificate. – Could create certificates with high privileges and allow modification of critical files. • If a company requires a higher level of protection several hardware-based solutions are available. © 201 2
- 37. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Private Key Protection • The key size should provide the necessary level of protection for the environment. • The lifetime of the key should correspond with how often it is used and sensitivity level of data. • The key should be changed at end of lifetime. • Key should be properly destroyed at end of lifetime. • The key should never be exposed in clear text. • No copies of the private key should be made. © 201 2
- 38. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Private Key Protection (continued) • The key should not be shared. • The key should be stored securely. • Authentication should be required before the key can be used. • The key should be transported securely. • Software implementations that store and use the key should be evaluated to ensure they provide the necessary level of protection. © 201 2
- 39. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Key Recovery • Key archiving is a way of backing up keys and securely storing them in a repository. • Key recovery is the process of restoring lost keys to the users or the company. • Dual control is when two people have to be present to carry out a specific task. – Can be used as part of a system to back up and archive data encryption keys – Can be configured to require multiple individuals to be involved in any key recovery process © 201 2
- 40. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition M of N Authentication • n number of people can be involved in the key recovery process, but at least m (which is a smaller number than n) must be involved before the task can be completed. • The goal is to minimize fraudulent or improper use of access and permissions. • This form of secret splitting can increase security by requiring multiple people to perform a specific function. © 201 2
- 41. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Key Escrow • Key escrow and key recovery are (incorrectly) used interchangeably. • Key escrow is the process of giving keys to a third party so that they can decrypt and read sensitive information if the need arises. • Key escrow almost always pertains to handing over encryption keys to the government, or to another higher authority, so that the keys can be used to collect evidence during investigations. © 201 2
- 42. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Public Certificate Authorities • Public CAs are already established and being used by many other individuals and companies. – Specialize in verifying individual identities and creating and maintaining their certificates – Issue certificates that are not bound to specific companies or departments • Some examples of public CAs are VeriSign (including GeoTrust and Thawte), Entrust, and Go Daddy. © 201 2
- 43. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition In-House Certificate Authorities • An in-house CA is implemented, maintained, and controlled by the company that implemented it. • This type of CA can be used to create certificates for internal employees, devices, applications, partners, and customers. • The company has complete control over how individuals are identified, what certification classifications are created, who can and cannot have access to the CA, and how the certifications can be used. © 201 2
- 44. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Choosing Between a Public CA and an In-House CA • Each company is unique, and many factors must be taken into consideration. – It is not just a financial decision. • Using public CAs – Public CAs already have the necessary equipment, skills, and technologies. • Using in-house CAs – Some companies do not trust an outside authority to generate and maintain their company’s certificates. © 201 2
- 45. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Outsourced Certificate Authorities • Outsource different parts of it to a specific service provider. – The more complex parts are outsourced, such as the CA, RA, CRL, and key recovery mechanisms. • It is used when the company does not have the necessary skills to implement and carry out a full PKI environment. • You must determine the level of trust the company is willing to give the service provider and what level of risk it is willing to accept. © 201 2
- 46. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition PKI Components Offered by a Provider © 201 2
- 47. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Tying Different PKIs Together • More than one CA may be needed. • Several requirements must be met for different PKIs to intercommunicate: – Seamless communication with business partners via a PKI – Needs to configure and control its own CA – Needs to have specially constructed certificates with unique fields and usages – Multiple CAs must be deployed – The political culture of a company inhibits one department from being able to control elements of another department. – Different sites need their own local CA © 201 2
- 48. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Trust Models • There are several forms of trust models. – Hierarchical, peer-to-peer, and hybrid • Trust domain is a construct of systems, personnel, applications, protocols, technologies, and policies that work together to provide a certain level of protection. • Most trust domains and need to communicate with other, less-trusted domains. • The trust anchor (the agreed-upon, trusted third party) © 201 2
- 49. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Trust Relationships © 201 2
- 50. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Hierarchical Trust Model • This model is a basic hierarchical structure that contains a root CA, intermediate CAs, leaf CAs, and end-entities. • The root CA is the ultimate trust anchor for all other entities in this infrastructure – It generates certificates for the intermediate CAs, – which in turn generate certificates for the leaf CAs, – and the leaf CAs generate certificates for the end-entities (users, network devices, and applications). • © 201 2 No bi-directional trusts exist, it is all top down.
- 51. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Hierarchical Trust Model © 201 2
- 52. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Verifying Certificates in a Certificate Path © 201 2
- 53. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Peer-to-Peer Model • One CA is not subordinate to another CA – No established trusted anchor between the CAs is involved. – End-entities will look to their issuing CA as their trusted anchor, but the different CAs will not have a common anchor. • One of the main drawbacks to this model is scalability. © 201 2
- 54. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Peer-to-Peer Model © 201 2
- 55. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Cross-Certification Models © 201 2
- 56. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Hybrid Trust Model • In a hybrid trust model, two companies have their own internal hierarchical models and are connected through a peer-to-peer model using crosscertification. • Another hybrid configuration is to implement a bridge CA. – Responsible for issuing cross-certificates for all connected CAs and trust domains – The bridge is not considered a root or trust anchor, but merely the entity that generates and maintains the crosscertification for the connected environments. © 201 2
- 57. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition A Bridge CA and the Cross-Certification Process © 201 2
- 58. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Certificate-Based Threats • Certificates bring much capability to security through practical management of trust however they also can present threats. • Much of the actual work is done without direct user involvement. • Can create a false sense of security. • If an HTTPS connection is compromised… – Spoofing, phishing, pharming, and a wide range of sophisticated attacks are possible. © 201 2
- 59. Principles of Computer Security:Security: Principles of Computer CompTIA Security+®®and Beyond, Third Edition CompTIA Security+ and Beyond, Third Edition Chapter Summary • Implement the basics of public key infrastructures. • Describe the roles of certificate authorities and certificate repositories. • Describe the role of registration authorities. • Explain the relationship between trust and certificate verification. • Use digital certificates. • Identify centralized and decentralized infrastructures. • Describe public and in-house certificate authorities. © 201 2
Editor's Notes
- #2: Public key infrastructures (PKIs) are becoming a central security foundation for managing identity credentials in many companies. The technology manages the issue of binding public keys and identities across multiple applications. The other approach, without PKIs, is to implement many different security solutions and hope for interoperability and equal levels of protection. PKIs comprise several components, including Certificates, registration and certificate authorities, and a standard process for verification. PKI is about managing the sharing of trust and using a third party to vouch for the trustworthiness of a claim of ownership over a credential document, called a certificate.
- #4: Authority revocation list (ARL) - A separate revocation list is maintained for CA keys that have been compromised or should no longer be trusted. CA certificate – The certificate belonging to a certificate authority Certificate – A cryptographically signed object that contains an identity and a public key associated with this identity. The certificate can be used to establish identity, analogous to a notarized written document. Certificate authority (CA) – An entity responsible for issuing and revoking certificates. Cas are typically not associated with the company requiring the certificate, although they exist for internal company use as well (such as Microsoft). This term is also applied to server software that provides these services. The term certificate authority is used interchangeably with certification authority. Certificate path – The validation path a certificate takes from CA to CA until it reaches the shared trusted anchor. Certificate repository - Is a general term that describes a centralized directory that can be accessed by a subset of individuals. Certificate revocation list (CRL) - A list of serial numbers of certificates that have been revoked Certificate server - Is the actual service that issues certificates based on the data provided during the initial registration process. Certification practices statement (CPS) - The CPS along with the CA determines the frequency with which the CRL is updated Cross-certificate - Is used when independent CAs establish peer-to-peer trust relationships. Digital certificate - A cryptographically signed object that contains an identity and a public key associated with this identity. The certificate can be used to establish identity, analogous to a notarized written document. dual control - Two people have to be present to carry out a specific task. end-entity certificates - AN end-entity certificate is the identity document provided by PKI implementations. hierarchical trust model - Is a basic hierarchical structure that contains a root CA, intermediate CAs, leaf CAs, and end-entities. hybrid trust model - In a hybrid trust model, the two companies have their own internal hierarchical models and are connected through a peer-to-peer model using cross-certification. key archiving system - Is a way of backing up keys and securely storing them in a repository key escrow - Is the process of giving keys to a third party so that they can decrypt and read sensitive information if the need arises. key recovery - Is a process that allows for lost keys to be recovered. local registration authority (LRA) - Performs the same functions as an RA, but the LRA is closer to the end users. Online Certificate Status Protocol (OCSP) - A request and response protocol that obtains the serial number of the certificate that is being validated and reviews revocation lists for the client. peer-to-peer trust model - One CA is not subordinate to another CA, and no established trusted anchor between the CAs is involved. policy certificate – The mechanism used to provide centrally controlled policy information to PKI clients. public key infrastructure (PKI) – Infrastructure for binding a pubic key to a known user though a trusted intermediary, typically a certificate authority. registration authority (RA) - Is the PKI component that accepts a request for a digital certificate and performs the necessary steps of registering and authenticating the person requesting the certificate.
- #5: “PKI is about managing the sharing of trust and using a third party to vouch for the trustworthiness of a claim of ownership over a credential document, called a certificate.” This is a important concept to understand, as the rest of the chapter essentially builds upon this definition and explains the various elements and how they relate. PKI is trust management by a trusted third party.
- #6: PKI boils down to establishing a level of trust. Public key encryption is a great way to secure the confidentiality of your information. However it is dependent upon having the correct public key! If the keys are publically stored and managed, who is checking to see if the keys actually belong to who they say they do? Who is making sure they are not swapped? If, for example, John and Diane want to communicate securely, John can generate his own public/private key pair and send his public key to Diane, or he can place his public key in a directory that is available to everyone. If Diane receives John’s public key, either from him or from a public directory, how does she know the key really came from John? Maybe another individual, Katie, is masquerading as John and has replaced John’s public key with her own, (referred to as a man-in-the-middle attack). If this took place, Diane would believe that her messages could be read only by John and that the replies were actually from him. However, she would actually be communicating with Katie. What is needed is a way to verify an individual’s identity, to ensure that a person’s public key is bound to their identity and thus ensure that the previous scenario (and others) cannot take place.
- #7: PKI works like the DMV. When John goes to register for a driver’s license, he has to prove his identity to the DMV by providing his passport, birth certificate, or other identification documentation. If the DMV is satisfied with the proof John provides (and John passes a driving test), the DMV will create a driver’s license that can then be used by John to prove his identity. Whenever John needs to identify himself, he can show his driver’s license. Although many people may not trust John to identify himself truthfully, they do trust the third party, the DMV.
- #8: Security + Objective 6.3d Public Key Continuing from the last illustration, if Diane can validate John’s digital certificate, then she can get his public key from it and use that to send an encrypted message. This helps prevent man-in-the-middle attacks.
- #9: Security + Objective 6.3a Certificate Authority A CA is more than just a piece of software, however; it is actually made up of the software, hardware, procedures, policies, and people who are involved in validating individuals’ identities and generating the certificates. This means that if one of these components is compromised, it can negatively affect the CA overall and can threaten the integrity of the certificates it produces. Warning: As noted in Chapter 5, it is important to safeguard the private key. Typically, it should never leave the machine or device where it was created. Every CA should have a certification practices statement (CPS) that outlines how identities are verified; the steps the CA follows to generate, maintain, and transmit certificates; and why the CA can be trusted to fulfill its responsibilities.
- #10: Security + Objective 6.3f Registration Authority Exam Tip: The RA verifies the identity of the certificate requestor on behalf of the CA. The CA generates the certificate using information forwarded by the RA.
- #12: The certificate authority owns a certificate server. The certificate authority has the certificate server issue a certificate, digitally signed with the certificate authority’s private key.
- #13: If an application creates a key store that can be accessed by other applications, it will provide a standardized interface, called the application programming interface (API). In Netscape and UNIX systems, this interface is usually PKCS #11, and in Microsoft applications the interface is Crypto API (CAPI). As an example, the figure shows that Application A went through the process of registering a certificate and generating a key pair. It created a key store that provides an interface to allow other applications to communicate with it and use the items held within the store. Different applications from the same vendor may share key stores. Microsoft applications keep user keys and certificates in a registry entry within that user’s profile. The applications can then save and retrieve them from this single location or key store. Other applications could also use the same keys if they knew where they were stored by using registry API calls.
- #14: A local registration authority (LRA) performs the same functions as an RA, but the LRA is closer to the end users. This component is usually implemented in companies that have their own internal PKIs and have distributed sites. Each site has users that need RA services, so instead of requiring them to communicate with one central RA, each site can have its own LRA. This reduces the amount of traffic that would be created by several users making requests across wide area network (WAN) lines. The LRA performs identification, verification, and registration functions. It then sends the request, along with the user’s public key, to a centralized CA so that the certificate can be generated. It acts as an interface between the users and the CA. LRAs simplify the RA/CA process for entities that desire certificates only for in-house use.
- #15: Public keys must be available to anybody who requires them to communicate within a PKI environment. These keys, and their corresponding certificates, are usually held in a publicly available repository. When an individual initializes communication with another, the sender can send her certificate and public key to the receiver, which will allow the receiver to communicate with the sender using encryption or digital signatures (or both) without needing to track down the necessary public key in a certificate repository. This is equivalent to the sender saying, “If you would like to encrypt any future messages you send to me, or if you would like the ability to verify my digital signature, here are the necessary components.” But if a person wants to encrypt the first message sent to the receiver, the sender needs to find the receiver’s public key in a certificate repository.
- #16: Security is about being suspicious and being safe. We need a third party that we do trust to vouch for the other individual before confidence can be instilled and sensitive communication can take place. But what does it mean that we trust a CA, and how can we use this to our advantage? When a user chooses to trust a CA, she will download that CA’s digital certificate and public key, which will be stored on her local computer. Most browsers have a list of CAs configured to be trusted by default, so when a user installs a new web browser, several of the most well-known and most trusted CAs will be trusted without any change of settings.
- #20: The IETF’s Public-Key Infrastructure (X.509), or PKIX, working group has adapted the X.509 standard to the more flexible organization of the Internet, as specified in RFC 3280, and is commonly referred to as PKIX for Public Key Infrastructure X.509.
- #23: In the model, the superior CA gives the authority and allows the subordinate CA to accept certificate requests and generate the individual certificates itself.
- #24: Several different extensions can be implemented, one being key usage extensions, which dictate how the public key that is held within the certificate can be used. Remember that public keys can be used for different functions: symmetric key encryption, data encryption, verifying digital signatures, and more. A nonrepudiation service can be provided by a third-party notary. If a company needs to be sure that accountable nonrepudiation services will be provided, a trusted time source needs to be used, which can be a trusted third party called a time stamp authority (TSA).
- #26: Warning: Setting certificate lifetimes way into the future and using them for long periods of time provides attackers with extended windows to attack the cryptography. As stated in Chapter 5, cryptography merely buys time against an attacker; it is never an absolute guarantee.
- #27: The act of verifying that an individual indeed has the corresponding private key for a given public key is referred to as proof of possession. If a key pair is used for encryption, the RA can send a challenge value to the individual, who, in turn, can use her private key to encrypt that value and return it to the RA. If the RA can successfully decrypt this value with the public key that was provided earlier, the RA can be confident that the individual has the necessary private key and can continue through the rest of the registration phase.
- #28: A renewal process is different from the registration phase in that the RA assumes that the individual has already successfully completed one registration round. The certificate may or may not need to change during the renewal process; this usually depends on why the renewal is taking place. If the certificate just expired and the keys will still be used for the same purpose, a new certificate can be generated with new validity dates. If, however, the key pair functionality needs to be expanded or restricted, new attributes and extensions may need to be integrated into the new certificate.
- #29: Exam Tip: A certificate cannot be assumed to be valid without checking for revocation before each use. Security + Objective 6.3 Explain the core concepts of public key infrastructure Security + Objective 6.4 Implement PKI, certificate management and associated components In the last instance, the certificate, which was bound to the user’s key pair, identified the user as an employee of the company, and the administrator would want to ensure that the key pair could not be used in the future to validate this person’s affiliation with the company. Revoking the certificate does this. Reasons for revoking - A user may have lost a laptop or a smart card that stored a private key An improper software implementation may have been uncovered that directly affected the security of a private key A user may have fallen victim to a social engineering attack and inadvertently given up a private key data held within the certificate may no longer apply to the specified individual An employee left a company and should not be identified as a member of an in-house PKI any longer. Warning: Once revoked, a certificate cannot be reinstated. This is to prevent an unauthorized reinstatement by someone who has unauthorized access to the key(s). A key pair can be reinstated for use by issuing a new certificate if at a later time the keys are found to be secure. The old certificate would still be void, but the new one would be valid.
- #31: The mechanism used to protect the integrity of a CRL is a digital signature. The CA’s revocation service creates a digital signature for the CRL, as shown above. To validate a certificate, the user accesses the directory where the CRL is posted, downloads the list, and verifies the CA’s digital signature to ensure that the proper authority signed the list and to ensure that the list was not modified in an unauthorized manner. The user then looks through the list to determine whether the serial number of the certificate that he is trying to validate is listed. If the serial number is on the list, the private key should no longer be trusted, and the public key should no longer be used. This can be a cumbersome process, so it has been automated in several ways, which are described in the next section.
- #33: One of the protocols used for online revocation services is the Online Certificate Status Protocol (OCSP), a request and response protocol that obtains the serial number of the certificate that is being validated and reviews revocation lists for the client. The protocol has a responder service that reports the status of the certificate back to the client, indicating whether it has been revoked, is valid, or has an unknown status. This protocol and service saves the client from having to find, download, and process the right lists.
- #34: If, for example, Bob is taking an extended vacation and wants to ensure that his certificate will not be compromised or used during that time, he can make a suspension request to the CA. The CRL would list this certificate and its serial number. In the field that describes why the certificate is revoked, it would instead indicate a hold state. Once Bob returns to work, he can make a request to the CA to remove his certificate from the list.
- #35: The goal is to make sure that no one can gain access to a key after its lifetime has ended and use that key for malicious purposes. An attacker might use the key to digitally sign or encrypt a message with the hopes of tricking someone else about his identity (this would be an example of a man-in-the-middle attack). Also, if the attacker is performing some type of brute-force attack on your cryptosystem, trying to figure out specific keys that were used for encryption processes, obtaining an old key could give him more insight into how your cryptosystem generates keys. The less information you supply to potential hackers, the better.
- #37: If a person obtained a root CA private key, she could digitally sign any certificate, and that certificate would be quickly accepted by all entities within the environment. Such an attacker might be able to create a certificate that has extremely high privileges, perhaps allowing her to modify bank account information in a financial institution, and no alerts or warnings would be initiated because the ultimate CA, the root CA, signed it.
- #40: Security + Objective 6.3c Recovery Agent Exam Tip: Key archiving is the process of storing a set of keys to be used as a backup should something happen to the original set. Key recovery is the process of using the backup keys. Exam Tip: Key recovery is a process that allows for lost keys to be recovered. Key escrow is a process of giving keys to a third party so that they can decrypt and read sensitive information when this need arises. What principle of security does dual control support? This enforces separation of duties, which means that one person cannot complete a critical task by himself. Requiring two individuals to recover a lost key together is called dual control, which simply means that two people have to be present to carry out a specific task.
- #41: Exam Tip: Secret splitting using m of n authentication schemes can improve security by requiring that multiple people perform critical functions, preventing a single party from compromising a secret. Be sure to understand the concept of m of n for the CompTIA Security+ exam. A company would not require all possible individuals to be involved in the recovery process, because getting all the people together at the same time could be impossible considering meetings, vacations, sick time, and travel. At least some of all possible individuals must be available to participate, and this is the subset m of the number n. Requiring too many people for the m subset increases issues associated with availability, whereas requiring too few increases the risk of a small number of people colluding to compromise a secret.
- #42: Security + Objective 6.3g Key Escrow Exam Tip: Key recovery is a process that allows for lost keys to be recovered. Key escrow is a process of giving keys to a third party so that they can decrypt and read sensitive information when this need arises. Exam Tip: Key escrow, allowing another trusted party to hold a copy of a key, has long been a controversial topic. This essential business process provides continuity should the authorized key-holding party leave an organization without disclosing keys. The security of the escrowed key is a concern, and it needs to be managed at the same security level as for the original key.
- #45: Decision depends on expansiveness of the PKI within the organization, how integrated it will be with different business needs and goals, its interoperability with a company’s current technologies, the number of individuals who will be participating, and how it will work with outside entities.
- #47: This diagram illustrates how one outsourced service provider can offer different PKI components and services to different companies, and how companies within one vertical market can share the same resources.
- #48: These situations can add much more complexity to the overall infrastructure, intercommunication capabilities, and procedures for certificate generation and validation.
- #49: Security + Objective 6.3h Trust Models Exam Tip: Three trust models exist: hierarchical, peer-to-peer, and hybrid. Hierarchical trust is like an upside down tree; peer-to-peer is a lateral series of references; and hybrid is a combination of hierarchical and peer-to-peer trust.
- #50: A trust relationship must be established between two issuing authorities (CAs). This happens when one or both of the CAs issue a certificate for the other CA’s public key, as shown in the above figure. This means that each CA registers for a certificate and public key from the other CA. Each CA validates the other CA’s identification information and generates a certificate containing a public key for that CA to use. This establishes a trust path between the two entities that can then be used when users need to verify other users’ certificates that fall within the different trust domains. The trust path can be unidirectional or bidirectional, so either the two CAs trust each other (bidirectional) or only one trusts the other (unidirectional).
- #52: NOTE: If the root CA’s private key were ever compromised, all entities within the hierarchical trust model would be drastically affected, because this is their sole trust anchor. The root CA usually has a small amount of interaction with the intermediate CAs and end-entities, and can therefore be taken offline much of the time. This provides a greater degree of protection for the root CA, because when it is offline it is basically inaccessible.
- #53: The certificate path, is the path needed to be taken to continue to track down and collect certificates until it came upon a self-signed certificate When a user in one trust domain needs to communicate with a user in another trust domain, one user will need to validate the other’s certificate. This sounds simple enough, but what it really means is that each certificate for each CA, all the way up to a shared trusted anchor, also must be validated.
- #55: The two different CAs will certify the public key for each other, which creates a bidirectional trust. This is referred to as cross-certification, since the CAs are not receiving their certificates and public keys from a superior CA, but instead are creating them for each other.
- #56: This figure represents a fully connected mesh architecture, meaning that each CA is directly connected to and has a bidirectional trust relationship with every other CA. As you can see in this illustration, the complexity of this setup can become overwhelming.
- #59: If a hacker wishes to have something recognized as legitimate, he may have to obtain a certificate that proves this point to the end-user machine. One avenue would be to forge a false certificate, but this is challenging because of the public key signing of certificates by CAs. To overcome this problem, the hacker needs to install a false, self-signed root certificate on the end-user PC. This false key can then be used to validate malicious software as coming from a trusted source. This attack preys on the fact that end users do not know the contents of their root certificate store, nor do they have a means to validate changes. In an enterprise environment, this attack can be thwarted by locking down the certificate store and validating changes against a white list. This option really is not very practical for end users outside of an enterprise.