3.9 Given a scenario, implement public key infrastructure

  • Public Key Infrastructure (PKI)
    • Key Management
    • Certificate Authority (CA)
    • Intermediate CA
    • Registration Authority (RA)
    • Certificate Revocation List (CRL)
    • Certificate Attributes
    • Online Certificate Status Protocol (OCSP)
    • Certificate Signing Request (CSR)
    • CN
    • Subject Alternative Name
    • Expiration
  • Types of Certificates
    • Wildcard
    • Subject Alternative Name
    • Code Signing
    • Self-Signed
    • Machine/Computer
    • Email
    • User
    • Root
    • Domain Validation
    • Extended Validation
  • Certificate Formats
    • Distinguished Encoding Rules (DER)
    • Privacy Enhanced Mail (PEM)
    • Personal Information Exchange (PFX)
    • .cer
    • P12
    • P7B
  • Concepts
    • Online vs Offline CA
    • Stapling
    • Pinning
    • Trust Model
    • Key Escrow
    • Certificate Chaining


Components

A Public Key Infrastructure or PKI has several important components, which work together.  It is a set of policies and procedures that regulate how we exchange encrypted data and authenticate people over the internet.

If you’ve been paying attention, Alice and Bob want to talk, but are far apart.  They have three main goals

  • They want to keep their communication secure from Eve (and everybody else).  This is known as confidentiality.

  • Alice wants to verify that it is actually Bob on the other side, and Bob wants to verify that it is actually Alice on the other side, even though they can’t see each other.  This is known as authenticity.

  • They want to make sure that nobody modifies their message along the way.  This is known as integrity.

Alice creates a private key, which she keeps secret, and she publishes her private key.  Bob does the same thing.

If Bob is a bank website or some other website, then we want to verify that we accessed the legitimate website.  Bob’s website has a certificate that says it was issued to his bank.  Then we know that we are at the real website.

But why should we trust the certificate?  Let’s take a look at the components of the PKI.

  • The CA is the Certification Authority.  The CA is responsible for issuing certificates to the users.  The CA is trusted to issue a certificate.  We are trusting Bob’s certificate because it was issued by an authority that we trust.  The most popular CAs are IdenTrust, DigiCert, Sectigo, and GoDaddy.  Together they have 98% of the market.

    • The CA will have a certificate of its own.  This is known as a root certificate.  It uses its certificate to digitally sign certificates that it issues.

    • A web browser or computer will automatically trust the certification authority.  Why?  It will be equipped with the root certificates of the most common authorities.  A user or organization can choose to trust additional CAs by installing their root certificates.

    • When a user attempts to visit a secure website, the website’s server will present a certificate.  The certificate proves the identity of the website.  The certificate will be signed by a certifying authority.

    • The user’s computer verifies the signature on the certificate.

  • Intermediate CA

    • Instead of signing a certificate with the root certificate, a CA can create a certificate known as the intermediate certificate.  The CA signs the intermediate certificate with its root certificate.

    • The CA then uses the intermediate certificate to sign the certificates that it issues.

    • Why?  If the root certificate is compromised, a hacker could create fake certificates and sign them.  The CA would need to revoke every certificate that it signed with that root certificate.  A large CA could have issued millions of certificates which would affect many customers.

    • The CA could create a tree of certificates.  It could create multiple intermediate certificates (signed by the root certificate), and then create multiple additional intermediate certificates, signed by the intermediate certificates.

    • When a user installs a certificate, they may need to also install and trust the intermediate certificates that have been used to sign it.  If an intermediate certificate is compromised, fewer certificates are vulnerable, then if a root certificate was compromised.

  • CRL

    • A CRL is a Certificate Revocation List

    • Each CA maintains a list of certificates that it has revoked prior to their expiry dates (certificates automatically expire after a specific period)

    • A certificate can be revoked

      • If it was improperly issued

      • Its private key was compromised

      • If the user violated the terms of use of the certificate issuer

    • The CRL is digitally signed by the CA.

    • Only the CA can modify an entry on the CRL.

    • Each time a certificate is presented, its validity should be checked against the CRL.  For example, each time you visit a website, your web browser will check that website’s certificate’s validity against the CRL.

    • The main problem with the CRL is that it requires a certificate checker to have an online connection to the CRL.  If the CRL is unavailable or unreachable, then the user will not be able to complete the operation requiring the certificate.

    • A user can make an offline copy of the CRL and validate certificates against the offline copy.  The disadvantage is that the offline copy may not be updated, which would cause a user to accept certificates that have been revoked.

    • A certificate can be suspended (put on hold).  A suspended certificate is effectively revoked but can be returned to active status.

  • OCSP

    • CRLs are being replaced with the Online Certificate Status Protocol

    • An OCSP request contains less data than a CRL

    • An OCSP responder is a server that receives requests to determine whether a certificate is valid.  The responder returns a yes/no response, which is digitally signed by the CA’s certificate.

  • CSR

    • How do we buy and install a certificate?  An applicant (a user/server that requires a certificate) creates a CSR or Certificate Signing Request and sends it to the CA to obtain the certificate

    • The applicant creates a private key and uses it to generate a public key

    • The applicant generates a CSR, which contains

      • Certification Request Information (the name of the applicant, the website/server that needs to be secured, etc.).  This information also includes the applicant’s public key.

      • Signature Algorithm Information

      • Digital Signature of the applicant

    • The CA receives the CSR and verifies that the information inside it is accurate

    • The CA creates a certificate using the information provided by the CSR, and signs it with its root or intermediate certificate

    • The CA encrypts the signed certificate with the applicant’s public key.  Remember that the CA must send the applicant a certificate over the internet that contains a private key, which cannot be disclosed to others.  Only the applicant can decrypt the signed certificate.  That is the reason for having the applicant create a public/private key pair.

  • Certificate

    • So what is a certificate?  A certificate is a file that proves the identity of a computer or person

    • The X.509 standard governs the format of each certificate

    • The certificate contains

      • The identity of its owner (this could also include the URL or IP address of the resource that it is securing)

      • An expiry date

      • An issue date

      • A digital signature of the CA that issued it

      • The name of the CA that issued it

      • A serial number

      • The permitted uses of the certificate

      • Additional information as required

  • Public Key

    • In public key cryptography, a public key is a key that is used to encrypt messages or verify digital signatures

    • The public key is generally publicly available so that others can use it to validate signatures and so that they can encrypt messages

    • It is important that a user relying on a public key can verify that a specific public key belongs to the user that it claims to belong to.  That is why the public key must be signed by the CA.

  • Private Key

    • The private key is secret

    • A private key is issued to a user or server

    • The private key is used to generate the public key

    • The private key is used to digitally sign documents and to decrypt messages that were encrypted with the corresponding public key

  • Object Identifiers (OID)

    • An object identifier is a unique number

    • Each item in the certificate is labeled with an object identifier

So, let’s summarize with an example

  • I run a banking website and I want to provide a certificate to prove my identity to my customers

  • I visit a CA’s website and buy a certificate

  • Then I go to my web server and create a CSR (Certificate Signing Request).  My web server generates a private key-public key combination.

  • I take the CSR to my CA (I download the CSR file from my server and upload it to the CAs website)

  • My CA generates a certificate for my website and signs it with their intermediate certificate (which is signed with their root certificate)

  • My CA encrypts the certificate with the public key from my CSR

  • I receive the certificate and install it on my server.  My server can decrypt it with the private key.

  • The CA also sends me a set of intermediate certificates and the root certificate, which I should also install.

  • When a user visits our website, their web browser checks our certificate and verifies that it is legitimate.  That means a few things

    • The certificate hasn’t been revoked

    • The certificate isn’t expired

    • The certificate is signed by a legitimate CA.  The web browser won’t recognize the intermediate certificates that have signed the certificate.

      • It will ask the server for the intermediate certificates. 

      • It checks that the certificate on the website is signed by an intermediate certificate

      • It checks that the intermediate certificate is signed by a root certificate belonging to a CA that it trusts

    • The certificate belongs to the website that is presenting it

Concepts

Some more ideas for how Public Key Cryptography is actually implemented

  • Online vs. Offline CA

    • An offline certificate authority is one that does not access the internet

    • Recall that the certificates are trusted from the root certificate to the intermediate certificate to the local certificate

    • The root certificate is precious.  If the root certificate is compromised, then all the certificates that it signed are also compromised.  There could be millions of certificates.

    • To keep it safe, the root certificate can be kept offline.  It can be brought online only when it is needed, such as when an intermediate certificate must be signed.

    • The root CA cannot host a Certificate Revocation List while it is offline.  That is not an issue if the root is used to verify multiple intermediate CRLs, each belonging to an intermediate certificate.

    • A Validation Authority is another server that can verify if a certificate is valid or not, on behalf of an offline root CA.  The validation authority will not be able to revoke a certificate, only verify its status.  The validation authority will receive updates from the CA when additional certificates must be revoked.

  • Stapling

    • The formal name of stapling is Online Certificate Status Protocol (OCSP) Stapling

    • It is a process for checking if a certificate has been revoked

    • The CA may receive billions of requests each day regarding the validity of a certificate

      • Each time a web page secured by a certificate is loaded, the user’s web browser asks the CA to validate the certificate.  Consider a website like Amazon.com, which has billions of page views each day.  Each time a user visits the website, its web browser checks the certificate.

      • The requests could burden the CA

    • The solution is stapling

      • The web server holding the certificate queries the CA at regular intervals

      • The CA responds with a proof of the server certificate’s validity, which is signed by the CA

      • When a user visits the website, the web server “staples” the signed response to its certificate, and sends the entire package to the user’s web browser

      • The web browser will only accept a stapled response that is signed by the CA and that is not expired; if the server is unable to provide a valid response, then the web browser will query the CA directly

    • If the certificate is revoked, but the stapled response is still valid, then it is possible for the user’s web browser to accept a revoked certificate

    • Not all web browsers support stapling, and not all web servers support stapling

  • Pinning

    • Key Pinning is a system where a certificate or key is associated with a host

    • Consider that a user needs to connect to a host (a server of some kind).  This could be a banking website for example.

    • Let’s look at the following example

      • You want to visit www.bankofamerica.com

      • A hacker could spoof bankofamerica.com’s DNS record and send you to his server

      • On his server, he builds an identical website to bankofamerica.com

      • He goes to the CA and buys a certificate for bankofamerica.com.  The CA might verify that the hacker owns bankofamerica.com before issuing the certificate, but there are some ways around this

      • Now the hacker has a website that looks legitimate and has a certificate issued by the CA

        How does the user know that it should trust this host?  How does the user know that this host is legitimate?

    • We can use pinning.  How does pinning work?

      • The first time that a device connects to a host, and the host presents a certificate, the device pins the certificate to the host.  In other words, the first time we visit the bank’s website, our web browser pins its certificate.

      • The device expects to see the same certificate on subsequent connections

      • A hacker would need to hijack this connection the first time that a host connects (which is unlikely)

      • The certificate can be pinned to an application during development.  This happens offline (before the application ever connects to the internet).  A hacker would not be able to pin a fake certificate unless he gained access to the development environment.

    • What can be pinned?

      • The certificate

        • Some web servers rotate their certificates (but the public key remains the same)

        • If an application pins a certificate that connects to a web server, then the application must be updated each time the certificate changes

        • Each time the application runs, it checks that the certificate it received from the host is the same one as the certificate that is pinned

      • The certificate’s public key – Subject Public Key Info

        • The key is pinned

        • It might be difficult to extract a public key from a certificate

        • The application verifies that the pinned key is the same as the key that is received

  • Trust Model

    • The trust model tells us how and when to trust a certificate.  There are several different trust models.

    • Direct Trust

      • Every certificate is trusted directly

      • The user who receives the certificate verifies its validity with the CA

      • Direct trust is difficult because if a CA issues millions of certificates, it may not have the capacity to trust all of them.

      • Also, we might not want to trust every CA that is out there.  Anybody can set up their own CA and issue certificates.

    • Hierarchical Trust

      • Each certificate is signed by CA

      • The user trusts the CA

      • If the user trusts the CA, then anything that the CA has signed is also trusted; therefore, intermediate certificates are also trusted

      • The certificates form a tree of trust

      • If a certificate is signed by something that the CA has indirectly signed, then it is trusted

      • The hierarchical trust only operates in one direction; the CA would never trust something signed by a user

      • If two users share a common trusted CA, they will trust each other provided they can verify the entire chain of certificates from each user to the CA

    • Indirect Trust

      • Certificates can be self signed, and self issued

      • A user or server can issue its own certificate.  An organization may issue certificates for its internal use because having many certificates signed by a public CA will be more expensive.

      • A self-signed certificate is not signed by a CA

      • The user marks the certificate in his computer as trusted if the user can verify its source

      • Users or organizations that self-sign certificates may or may not maintain a CRL to notify stakeholders of the certificate revocation status

      • An organization can configure user devices to trust certificates that it has issued.  This allows the organization to implement PKI cost-effectively.

    • Peer-to-Peer Trust

      • When users do not share a common CA but must find a way to trust each other, they can use a Peer-to-Peer Trust

      • The participating CAs issue bidirectional certificates indicating that they trust each other

      • Since each user trusts everything that their CA trusts, then each user trusts the users belonging to the other CA

      • A Peer-to-Peer trust can function across multiple CAs, but then each CA must issue certificates for each of the other CAs in the group

  • Key Escrow

    • Some people feel that the government should be able to decrypt any form of encrypted communication, if it has a valid court order. 

    • People who don’t understand technology say that we should put back doors into encryption.  Why is a back door bad?  If we put a back door into encryption technology, the government can use it to unlock encrypted data, but then so can hackers.  Hackers (especially those working for foreign governments) have unlimited resources.  They are already looking for security holes in technology.

      Once the identity of the back door is leaked or discovered, then the technology that uses it will be vulnerable.  A hacker who discovers a back door will use it to exploit the technology and might do so for years before it becomes known to the public.

    • The other idea was a key escrow.  Each person who uses encryption must deposit their private key in an escrow.

    • If an encrypted communication is used to commit a crime, the government can go to a court and obtain an order allowing it to obtain a key from the escrow and decrypt the data.

    • The government may also be able to obtain the key from the escrow without a court order in the event of a threat to national security or to the life of an individual

    • A key escrow is bad because a corrupt individual in the government could use the escrow to unlock encrypted communications without any court order

    • A key escrow could be hacked by a rogue third party or a foreign government.  If the government has access to private keys, then anybody could have access to private keys.

    • No key escrow exists in the United States or Canada, although the government has attempted to introduce one in the past

    • There are some key disclosure laws which require persons to disclose their private keys in response to a court order. It varies from country to country.

      • In Canada, a court will not compel key disclosure because people have the right to not self-incriminate themselves

      • In the United States, courts have ruled in favor of key disclosure and have also ruled against key disclosure.  It is difficult to predict how a court will rule.  We will discuss this in more detail in a later section.

      • In the UK, The Regulation of Investigatory Powers Act requires an individual to disclose keys even without a court order



  • Certificate Chaining
    • A certificate chain is an order of certificates beginning at the root and continuing through the intermediate certificates and then to the final user certificate

    • Each certificate is signed by the certificate above it (the intermediate certificate is signed by the root certificate and the user certificate is signed by an intermediate certificate)

    • The root certificate is not signed

    • If a user trusts the root certificate, then the user will trust any certificate in the chain.  A modern computer will trust the root certificates for the major CAs.  An computer belonging to an organization will be configured to trust the root certificates belonging to the organization.

Types of Certificates

There are many types/features of certificates.  A certificate can contain more than one feature.

  • Wildcard.  When we buy a certificate from a CA, that certificate only works on a specific server or domain name.  We can’t put it anywhere we want.  A wildcard certificate is one that can be used with multiple subdomains

    • Consider that amazon.com is a domain

    • If the amazon.com domain is secured by a wildcard certificate, then www.amazon.com, books.amazon.com, aws.amazon.com, and any other subdomain is also protected by the same certificate.  The wildcard certificate would be called *.amazon.com

    • Typically, a certificate will protect the root domain (amazon.com) and the www subdomain (www.amazon.com) at no additional cost.  A wildcard certificate that protects all subdomains is more expensive.

    • A wildcard certificate may not secure the second level subdomain such as fiction.books.amazon.com, unless the certificate is issued as a wildcard for books.amazon.com.  The wildcard certificate would be called *.books.amazon.com

    • The following types of wildcards are not permitted by any CA

      • * (this would secure every possible domain)

      • *.com (this would secure every possible .com domain)

      • *.*.domain.com (this is a certificate with multiple wildcards in the same domain)

      • books.*.domain.com (this is not allowed because the wildcard is in the middle of the domain)

      • abcd*.domain.com (this is a partial wildcard; it would allow domains like abcdefgh.domain.com; it is allowed, but not accepted by major web browsers)

  • SAN

    • A Subject Alternative Name certificate allows a user to host multiple SSL websites on the same IP address (typically an IP address must be bound to a certificate).  Because IPv4 addresses are limited, a company may choose to host multiple websites on the same web server/IPv4 address.

    • A SAN also allows a user to secure multiple domain names on the same certificate


  • Code Signing

    • A code signing certificate allows a software developer to digitally sign their application

    • The users can verify that the software they are running is the legitimate version.  This does not protect users if somebody hacks the software developer and adds malicious content before the code is signed, as was the case with the SolarWinds breach.

    • Windows by default will not allow a non-digitally signed driver to be installed

    • Windows by default will not trust a software application that is not signed.  Windows will display an alert saying that the publisher is unknown and discourage the user from running it.

    • An application should verify that software updates are signed by the legitimate developer before installing them.

  • Self-Signed
    • A self-signed certificate is one that is signed by the user that issued it

    • A self-signed certificate does not cost a user anything (as opposed to a CA-signed certificate which could cost thousands of dollars)

    • The entity that signed a self-signed certificate could always generate a new certificate and sign it.  Therefore, the values of the certificate should be manually validated before it is trusted.

    • We don’t want to trust a self-signed certificate unless we trust the user and we can verify that the certificate hasn’t been modified.

  • Machine/Computer

    • A machine/computer certificate secures a physical computer.  It verifies the identity of the computer to the network.

  • Email

    • An email certificate allows a user to secure and digitally sign an e-mail

    • It is installed inside an e-mail application, such as Outlook

  • User

    • A user certificate verifies the identity of a user.  It is not attached to any computer.  The user certificate may be attached to a smart card or token.

  • Root

    • The root certificate is issued by the CA and is used to sign its intermediate certificates and any other certificates issued by the CA

  • Domain Validation

    • A domain validation certificate verifies the identity of a server

    • The CA verifies that the person requesting a domain validation certificate is the owner of the domain (through whois records)

    • www.example.com has a domain validation certificate, then users can be assured that they have accessed a web server that belongs to that domain (as opposed to having arrived at a rogue server because of DNS hijacking)

    • How does a CA validate that you own the domain name?

      • It asks you to add a TXT record to the DNS of the domain name.  The TXT record consists of a random string generated by the CA

      • It sends an e-mail to admin@domainname.com, webmaster@domainname.com, or some other e-mail address that indicates management of the domain name

      • It asks you to put a small text file in the root directory of the website.  The text file consists of a random string generated by the CA.

  • Extended Validation

    • An extended validation certificate verifies the identity of a server.  It also validates the legal entity that owns the domain/server.

    • The CA verifies that the person requesting a domain validation certificate is the owner of the domain.  The CA also verifies the telephone number and physical address of the owner of the domain

    • An extended validation certificate is more expensive than a regular domain validation certificate

    • Web browsers previously displayed extended validation certificates with a green address bar, which also showed the name of the company to whom the certificate was issued.

    • EV certificates are no longer popular

    • For example, if a rogue individual purchased www.amaz0n.com and attempted to secure it

      • The rogue individual would be able to obtain a domain validation certificate (since he is the owner of the domain)

      • The individual would not be able to obtain an extended validation certificate (at least not in the name of Amazon.com Inc., but possibly in the name of their own company); unless the individual managed to register a business entity with the same name but a different state.  For example, Amazon.com is incorporated in Delaware; if an individual registered the company name in Texas, he could obtain a certificate in the name of Amazon.com. 

        Amazon would need to be vigilant and protect their name from people who tried to do this.

    • It is not possible to obtain a wildcard extended validation certificate

    • The maximum duration is 397 days

Certificate Formats

X.509 is a standard that defines the public key certificate format.

The structure of the certificate

  • Certificate
    • Version Number
    • Serial Number
    • Signature Algorithm ID
    • Issuer Name
    • Validity period
      • Not Before
      • Not After
    • Subject name
    • Subject Public Key Info
      • Public Key Algorithm
      • Subject Public Key
    • Issuer Unique Identifier (optional)
    • Subject Unique Identifier (optional)
    • Extensions (optional)
  • Certificate Signature Algorithm
  • Certificate Signature

There are several file formats for storing a certificate.  A certificate can be transformed from one format to another.

  • DER

    • Distinguished Encoding Rules

    • Stored in binary format

  • PEM

    • Container that could contain a single certificate or multiple certificate chains

    • A PEM file is a DER file that is base64 encoded

  • PFX

    • Encrypted PEM file

    • The PFX file contains the public and private certificates

    • The PFX file can be decrypted into public and private certificates

    • A user can export the public and private certificates into a PFX file, which can then be transferred to another server

  • CER

    • Canonical Encoding Rules

    • Stored in ASCII format

    • Recognized as a certificate by Windows (PEM is not)

  • P12

    • Encrypted PEM file

    • The P12 file contains the public and private certificates

    • The P12 file can be decrypted into public and private certificates

  • P7B

    • PKCS number 7

    • Certificate format used by Windows for key interchange