Understanding and Implimenting PKI

  1. Introduction

Public Key Infrastructure is a tool belt of technologies used to manage, request, create, store, distribute, and revoke digital certificates. Public Key Infrastructure uses asymmetric encryption. This means that there are two keys involved with the transportation of information. Both a public key and a private key. Asymmetric encryption provides a variety of purposes, such as protecting Personally Identifiable Information which includes: passwords, email addresses, social security numbers, bank account information. If it were not for public key infrastructure your information would be otherwise seen in clear text and flown across the web. For example, HTTP traffic ran over port 80 and the use of protocol analyzer (Wireshark) could be used to see traffic in the clear. The addition of HTTP plus TLSv2 makes the traffic encrypted in conjunction with the issued public key from the Certificate Authority. For those that are unfamiliar, this makes the lock icon in your browser.

Literature Review

The most important element of Public Key Infrastructure is the Certificate Authority. The CA (Certificate Authority) oversees the issuing, managing, validating, and revoking of digital certificates. There are two types of certificate authorities, public CA’s and private CA’s. A public CA would be an organization that sells certificates. An example of a paid certificate would be an organization such as Verisign or DigiCert. In recent years, getting a certificate has become free, thanks to an organization such as Lets Encrypt. Let’s Encrypt is a free, open, and automated CA which promotes the use of a more secure internet.

However, for this to work a public CA must be trusted. Additionally, if the CA is trusted, all certificates issued by the CA are trusted (Gibson, 2017). This is similar in the way a college issues a student their degree. Since the state accredits the college that they meet higher-level education requirements. The student will be trusted that they are knowledgeable about the job they are applying for. On the contrary, if a student where to go to a non-accredited college, the business is a lot less likely to trust their abilities. In brief, this is similar to the way computers trust certificates. This trust lies in the way we chain certificates and model trust.

In regards to certificate chaining and trust models, the root certificate is the first certificate created by the CA. Root certificates on Windows are placed in the Trusted Root Certification Authorities Certificate Store. If the CA’s certificate is placed in this store, then all the certificates issued by the CA are trusted (Gibson, 2017). You can view the Trusted Root Certificate Authorities Certificate Store by typing in the Windows search bar “CertMgr”. Down below depicts the Trusted Root Certificates in Windows:

In addition, a CA such as Digicert or GlobalSign can cut a deal with developers to put their certificates in web browsers. This ensures that their certificates are automatically trusted when users visit a website with their certificate. In addition, there are multiple types of trust models including bridged trust, direct trust, indirect trust, and hierarchical trust. Notably, the hierarchical trust model is the most prevalent. Likewise, a trust chain includes the following elements:

  • The Root CA issues certificates to the intermediate CA’s.
  • Intermediate CA’s issue certificates to issuing CA’s.
  • Issuing CA’s issues certificates to end-users.

Furthermore, Certificate Chaining is an ordered list of all certificates that start from the Root CA. This list continues down to the end-user. For instance, the picture below depicts the Starfield Root Authority, which then issued a certificate to Amazon, and LucidChart received a wildcard certificate from Amazon. A wildcard certificate allows a domain to have multiple subdomains while reducing cost. The reduction in cost occurs because the organization doesn’t have to purchase multiple certificates for each subdomain.

Contrarily, some smaller organization issue their certificates themselves. Usually, this is done to save money or everything within the organization is done locally. Hence, a Public CA is then not needed. Furthermore, the software used by Administrators to create these certificates includes OpenSSL, LebreSSL, BoringSSL, Windows IIS Server, and GnuTLS.

However, in recent years with OpenSSL, there have been vulnerabilities such as Heartbleed and Downgrade attacks. In response, BoringSSL and LebreSSL are forked from the OpenSSL repository. To prevent downgrade attacks from happening, just update and configure your server to use the latest updates.

In addition to trust models, a web of trust otherwise known as a decentralized trust model is often used with PGP and GPG. A decentralized trust model uses self-signed certificates. These certificates are trusted by 3rd party members. To illustrate, your group of friends trusts you. However, you bring another friend from outside the group into the group. Since you and your friend knows them as well, you can then vouch for them. This person will now be trusted since two members of the group have consensus. Consequently, this method doesn’t always work. Thus, if the third party is not a reliable source, then it will not be trusted.

In addition to a Certificate Authority, “a Registration Authority operates under the trusted collaborations of the certificate authority and can handle day-to-day functions, such as verifying registration information, generating end-user keys, revoking certificates, and validating user certifications (Whitman & Mattford, 2018).”  Usually, the Registration Authority has a user interface on the CA website. A good example is Let’s Encrypts website www.sslforfree.com. The first thing you would do would be to submit a certificate signing request. This request includes information about your website, name, and email address. Sometimes, the verification process includes extensive checking. Such as verifying the credit card you used to purchase the certificate. Secondly, you would then validate ownership either by automatic FTP Verification or Manual DNS Validation. If you go the manual DNS Validation route it can take up to 48 hours to propagate. By validating your identity, this creates a better security standard and proves ownership.

Another important factor is that the CA is in charge of revocation of the certificates. However, the Registration Authority is the one that handles this function. Most of the time, certificates will expire due to age. However, there are times when a CA will need to revoke the certificate not due to age. A certificate can be revoked for the following: Key compromise, CA compromise, Change of affiliation, Cease of operation, and Certificate hold (Gibson, 2017). In addition, a CA keeps a list of certificates that are revoked called a Certificate Revocation List. This helps the CA keep track of revoked certificates. As you can see down below the revoked certificates are ordered by serial number and revocation date.

  • Issues with Certificates

One of the major issues facing us today is that it may no longer be feasible for a CA to manage a CRL (Samoshkin & Samoshkin, 2018). As the web has grown exponentially in size it becomes difficult for a CA to keep track of the CRL. Clients can also validate the certificates by requesting a copy of the CRL. However, end clients usually ignore this. In the past, your browser would just use the CRL to check for expired, non-trusted, or improperly managed keys. The downside to this is that the lock icon would still appear green. As you can see in the exhibit, the certificate has expired but chrome is still showing that the connection is secure (Samoshkin & Samoshkin, 2018).

Recently, browsers have started implementing Online Certificate Status Protocol (OSCP). OSCP allows the client to query the HTTP server, providing real-time responses. From there, the concerned client sends an OSCP request to the CA. Next, the OSCP responder uses the certificate serial number to check the status and returns this status to the client. This status can only have three possible values: good, bad, or unknown. In addition, the CA responder keeps frequent updates with the CRL server to make sure this list is current. As you can see, rather than having to download the entire CRL list and search to see if a certificate is valid. Thus, reducing the burden on the client. 

However, this is not perfect. If the client fails to connect to the CA then it’s forced to decide between two options: neither are coveted. Firstly, the client chooses to connect anyway, defeating the purpose of certificates status checking. Secondly, it may choose to terminate the connection assuming something is wrong with the certificate (false alarms). However, there is a better solution called OCSP Stapling. With OSCP stapling the web server checks the status for all of its clients. The exhibit down below helps depict the difference between OSCP and OSCP stapling. Lastly, one of the benefits of OSCP stapling is that it creates a faster connection and reduces the overhead of all parties.

Storage, Recovery, and Formats

Additionally, one of the problems with digital keys is placing it in a safe environment. If a CA’s private key is compromised, then all certificates issued by the CA are compromised. Furthermore, the private key is kept on the Root CA server. The Root CA should always be offline as being online could compromise the key. Following that, the intermediate CA’s should also be kept offline.

However, what happens if your organization is concerned with a key being lost? This is where a key escrow comes in handy. A key escrow is a process of copying a private key and keeping it in a secure location (Whitman & Mattford, 2018). Usually, if your organization is big enough they will implement a key escrow service within their organization. Thus, reducing the likely hood of the key becoming lost. In addition, to a key escrow, a recovery agent is a person designated to the recovery and storing of the key. Depending on your organization’s security policies, multiple recovery agents will be designated to the recovery of the key. These persons must be present when with the key. This prevents personnel from making unauthorized duplicates of the key. Lastly, your organization may encrypt those keys as well, adding another layer of security.

In addition to certificates, knowing the type of certificate to use is crucially important. These certificate types include machine, user, email, code signing, self-signed, Wildcard, Subject Alternative Name (SAN), Domain Validation, Extended Validation (Gibson, 2017). Most of which I have covered in the previous text. These certificate types normally use the  X.509 v3 data structure and include the following information:

In addition to certificates, knowing the type of certificate to use is crucially important. These certificate types include machine, user, email, code signing, self-signed, Wildcard, Subject Alternative Name (SAN), Domain Validation, Extended Validation (Gibson, 2017). Most of which I have covered in the previous text. These certificate types normally use the  X.509 v3 data structure and include the following information:

Additionally, each type has a common type and extension which have different purposes. PEM stands for Privacy Enhanced Mail format and is the most prevalently used. Although the name has the word mail in it, on the contrary, they are used for everything. One thing to remember is that PEM has multiple file extension including .pem, .crt, .cer, and .key. Also, another key point is that .crt is not a valid certificate type. However, some PEM certificates do you the .crt extension. Lastly, PEM certificates can either be formatted in CER (binary) or DER (ASCII files). Similarly, PKCS#7 only uses DER-based (ASCII). These certificates are only used to share the public key and do not contain the private key. Commonly, they are used with Microsoft Windows and Java Tomcat. Lastly, PKCS#12 uses binary(CER) formatting and are most commonly used when working with Windows Server.

Conclusion

In conclusion, I have covered all the key concepts of Understanding and Implementing Private Key Infrastructure. In recent years, PKI has become less expensive for website owners. Although, if you wish to become a public CA, the expense is extraordinarily expensive. However, I do encourage those to set up their own private CA and sign their own certificates. In the past few semesters, PKI has become very familiar to me. As part of my classes, I have had to set up websites and configure several servers to accept the certificates from the CA. In addition, to managing certificates for Amazon Web Services. Writing this paper will be an integral part of my journey to achieving CompTIA’s Security+ Certification.

References

Gibson, D. (2017). CompTIA Security: Get certified get ahead: SY0-501 study guide. Virginia Beach, VA: YCDA, LLC.

Whitman, M. E., & Mattord, H. J. (2018). Principles of information security. Boston, MA: Cengage Learning.

Samoshkin, A., & Samoshkin, A. (2018, January 04). SSL certificate revocation and how it is broken in practice.

Leave a Reply
Previous Post
web developer

Become a Front-End Web Developer in Six Months

Next Post
virtual box

Intro to Virtual Machines (Virtual Box) and Linux, Part 1

Related Posts
Skip to content
Share via
Copy link
Powered by Social Snap
Close Bitnami banner
Bitnami