6.4 Given a scenario, implement public key infrastructure. Flashcards
Components
The term public key infrastructure comes from the fact that there is an entire infrastructure of components that help create this environment in which to manage and use public and private keys.
Components - CA (Certificate Authority)
Public CA
A public CA is used to identify CAs that are in the business of selling certificates to other businesses so those certificates can be used in applications. The benefit of a public CA is that most applications (such as Internet Explorer) trust certificates that come from common public CAs, such as Entrust, Verisign, and GoDaddy.
Private CA
When an organization decides to create its own PKI, it is a private CA. This allows an organization to create its own CA and use it to generate certificates for the organization. The benefit of using a private CA is that the organization does not have to pay for each certificate that is created.
Components - Intermediate CA (Subordinate CAs)
Depending on the size of the organization, you can create one or more subordinate CAs, also known as intermediate CAs. These CAs have their own certificate—issued and digitally signed by the root CA that they will use to digitally sign any certificates that they create. You might use subordinate CAs so that each office location has its own CA to issue certificates for that location, for example. And then take the root CA offline for the sake of security.
Components - CRL
As noted, your certificate can be revoked by the CA at any time if the CA determines that you were fraudulent in obtaining the certificate or there has been a security compromise related to your certificate.
The CA is responsible for creating the certificate revocation list (CRL), which is a list of certificates that have been revoked. The CRL is published to a web site at regular intervals, and applications download the CRL to verify that a certificate has not been revoked before using the certificate.
Components - OCSP
Another method that systems and applications can use to verify whether a certificate has been revoked relies on the Online Certificate Status Protocol (OCSP). OCSP is an Internet protocol that uses HTTP to communicate with the CA and check the status of a certificate. OCSP is designed as an alternative to the CRL.
***
It should be noted that when using OCSP, the revocation status can be communicated to clients using a feature called stapling.
With stapling, the web site that contains the certificate polls the CA at regular intervals to check to see if the certificate has been revoked. The status of the certificate is then sent from the web server to any clients visiting the web site during the initial handshake. This prevents the clients from bogging down the CA to check the status of the certificate.
***
Components - CSR
When configuring SSL on a web site, or applying certificates to any application, there are four major steps:
1. Create the request
The first step is to create the certificate request, also known as the certificate signing request (CSR). You typically navigate to the web site of the CA to fill out a web form to create the request or create the request from the actual application. For example, Microsoft’s IIS and Exchange Server have wizards to create the certificate request. Once the request is made, it is stored in a text file. You can also create a certificate request from the Certificates snap-in within MMC.
- Submit the request
- Download the certificate
- Install the certificate
Components - Certificate
A certificate is an electronic file that is used to store the public key (and sometimes the private key) and associates the public key with an entity such as a person or company.
For example, if you are hosting a web site and wish to secure the communication, you need to configure the web server with a public key. You obtain a certificate (which contains the public key) and assign it to the web server in order to encrypt the communication.
As mentioned, the certificate stores the public key and also contains information about the owner of the public key. For this reason, the certificate is also considered an electronic file that binds the public key to its owner.
Attributes of a certificate:
Public key
The public key of the person who owns the certificate
Algorithm
The asymmetric algorithm used by the certificate
Serial number
A unique serial number assigned to the certificate
Subject
The name of the organization or person to whom the certificate is assigned
**
Take special notice that the Subject attribute is set to www.certworld.loc. This is sometimes referred to as the common name of the certificate, and it should match the URL that users access for the application that uses the certificate
**
Issuer
The organization or entity that created the certificate
Valid from
The start date of the period for which the certificate is
valid
Valid to
The end date of the period for which the certificate is valid
Thumbprint algorithm
The algorithm used to create a hash of the certificate to ensure it is not altered
Thumbprint
The hash value of the certificate
Components - Public Key
The public key gets its name from the fact that it is available to any parties in the infrastructure
Components - Private Key
The private key is to be kept private to the user.
Components - Object Identifiers (OID)
a PKI is made up of a hierarchy of CAs. The root CA has a self-signed certificate. Also note that all objects in a PKI use object identifiers, or OIDs. An OID is a globally unique name assigned to each object.
Concepts
.
Concepts - Online vs. Offline CA
One of the reasons to have subordinate CAs, or intermediate CAs, is so that you can take the root CA offline. Taking the root CA offline means that you are disconnecting it from the network so that it cannot be hacked. Within a PKI, if there is a security compromise with a CA, whether it be a root CA or a subordinate CA, then every certificate below that point should be considered compromised. If the root CA were hacked, the entire PKI would be considered compromised because everything falls under the root CA. To prevent needing to re-create all certificates and subordinate CAs, you typically take the root CA offline once you have subordinate CAs to generate certificates for the rest of the company.
Once a subordinate CA has been created for each of the locations, you should then power off the root CA so that it is not compromised. If a security compromise occurs, anything from that point in the hierarchy down is considered compromised and invalid. Taking the root CA offline ensures the root level is not compromised.
Concepts - Stapling
With stapling, the web site that contains the certificate polls the CA at regular intervals to check to see if the certificate has been revoked. The status of the certificate is then sent from the web server to any clients visiting the web site during the initial handshake. This prevents the clients from bogging down the CA to check the status of the certificate.
Concepts - Pinning
Another term to be familiar with as it relates to revoked certificates or certificate fraud is HTTP Public Key Pinning, or HPKP. Pinning allows web sites to publish a list of public key hashes that it potentially will use to secure the communication. When clients connect to the web server, the hashes are communicated to the client so that the client knows which public keys it can trust. This helps in scenarios where the hacker compromises a CA and creates its own certificates.
Concepts - Trust Model
PKI Trust Models: Whom do you trust?
STI Graduate Student Research
by Blaine Hein - July 28, 2015
There has been a substantial amount of attention in the media recently regarding Public Key Infrastructures (PKI). Most often, secure web server exploits and signed malware have generated this attention and have led to the erosion of trust in PKI. Despite this negative media attention, there has been very little detailed discussion of the topic of PKI Trust proliferation and control. PKI is an integral part of our daily lives even though, for the most part, we never notice it. Europe is several years ahead of North America in the ubiquitous deployment of PKI to its citizens, but North America has begun to catch up. This paper covers four major areas including the definition of trust and trust models, implementation of trust, auditing of trust, and managing trust. The paper provides proof of concept tools to allow administrators to understand their current level of PKI trust and techniques manage trust.
Trust anchors are a core concept within public key infrastructures. They are certificates that we believe in without needing to find further evidence (Housley, Ashmore, & Wallace, 2010). To use a building analogy, they are the cornerstone. Every other stone comes after the corner stone. Compromising the integrity of the cornerstone
can cause a building collapse.
***
More info on this:
https://www.sans.org/reading-room/whitepapers/vpns/paper/36112
Concepts - Key Escrow
Key escrow is the process of handing cryptography keys over to a third party who can use the cryptography keys to decrypt information within your organization at any point in time. For example, you may be required to give cryptography keys to a government agency or to law enforcement for an investigation.
The concept of key escrow is a controversial topic due to the obvious security risks of having keys that can decrypt information within your organization located outside the organization.
Concepts - Certificate Chaining
Unlike buildings, which start from the bottom up, building PKI certificates is a top-down process. First, the self-signed Root CA certificate is established. Next, the Root CA signs a subordinate CA certificate. This subordinate CA may, in turn, create an additional subordinate CA. The lowest layers of subordinate CAs issue certificates to people, applications, or devices. The minimum number of Certificate Authorities to establish a chain is one. While there is no theoretical maximum, the average certificate chains have between two and three CAs in the hierarchy.
More on this:
https://www.sans.org/reading-room/whitepapers/vpns/paper/36112
