BYU logo Computer Science
CS 465 Introduction to Security and Privacy

Certificates

Introductions

  • introductions of two students

Questions on the readings

The readings today are from Computer Security and the Internet, Chapter 8, sections 8.0-8.3, 8.5.

Public key certificates

  • a public key certificate associates a public key with an owner

    • combination of Subject and public key signed by a Certification Authority (CA)
    • a relying party relies on this certification authority and trusts its signature

  • we typically use a set of standards from the International Telecommunication Union (ITU) — X.509

Table 8.1 fields in a certificate

Issuing a certificate

  • Certificate Authorities (CAs) can issue certificates for humans, computers

    • web: issue to a web server to certify a public key is associated with a hostname
    • email: issue to a person to certify a public key is associated with an email address
    • code signing: issue to an organization to certify a public key is associated with that organization (name, location, company officer)

  • evidence needed to issue a certificate include

    • ownership of the key using challenge/response
    • ownershp or control of the entity in the Subject field (email address, web server, organization)
    • affiliation with a named legal entity

  • can easily get a website certificate for free with Let’s Encrypt

    • It uses a protocol called ACME to automatically verify you own a domain
    • For example, you contact an ACME server to request a certificate, and it gives you a file to serve from your website, once it verifies that you are serving it, then it issues you the certificate
    • see Let’s Encrypt Stats

Verifying a certificate

  • anyone can sign their own certificate, called a self-signed certificate
    • but it won’t necessarily be trusted!
  • the web uses a CA-based trust model:
Browser trust model
  • we use a trust model that assumes some trust anchors (trusted certificates) are shipped with browsers and operating systems
    • called a trusted certificate store or root store
  • each CA can forms a root of trust
  • other trust models are possible! the book covers some of them
verifying a certificate

  • Validating a certificate chain

    • obtain a certificate chain
      • you may have only the leaf or you may be given a partial chain
      • trace signatures back to a root and look up certificates as needed
    • for each certificate
      • check that it is not expired and is current
      • check that it is not revoked (see below)
      • check that the signature is valid using the signing CA’s public key
      • use is consitent with constraints (see below)
      • subject name matches semantics
        • hostname signed is the hostname the user is visiting in the browser
        • email address that is signed is the email subject
      • signing CA either has a public key that is trust anchor, or repeat above steps until reaching a trust anchor

  • constraints

    • basic constraints
      • includes whether the public key is for a CA (and thus can sign other certificates), otherwise it is a leaf certificate
      • includes a chain length, 0 means the CA can only issue leaf certificates
    • key usage
      • allowed uses, e.g. for signatures, encyption, key agreement, revocation list signatures, code signing
    • subject alternate name
      • various alternative aliases (other email addresses, other domain names or IP addresses)
    • name constraints
      • constrains what a CA can sign for (e.g. only .com or only .byu.edu domains)

Revoking a certificate

  • needed in case

    • a private key is stolen
    • a private key is lost
    • changes to name or organization
    • new key pair

  • Certificate Revocation List (CRL)

    • issued by a CA
    • contains a list of all unexpired but revoked certificates
    • can be fetched by a browser / RP periodically
    • major drawback is size, especially for mobile devices

  • Online Certificate Status Protocol (OCSP)

    • allows a browser / RP to check the revocation status of a certificate
    • major downside is privacy concern
      • CAs now have knowledge of your browsing habits
      • note, ISPs already have this
    • another major concern is “failing open”
      • if fetching OCSP status fails, the browser still visits the site (otherwise users are unhappy)
      • this makes it easy for an attacker to deny access to OCSP and thus carry out an attack with a revoked certificate
    • another concern is delay
    • OCSP stapling
      • a web server gets a signed, timestamped certificate of the validity of the certificate
      • provides this to the web browser when fetching its certificate
      • eliminates the delay concern
      • stapling can still be deleted/removed by an attacker, leading to the “failing open” problem
      • web sites can use “OCSP must staple” in their certificates, indicating that if the staple is stripped, that is a problem
      • attacker can still strip it and cause denial of service
      • website owners can mess it up and cause outage for customers

  • current approach is to use compressed CRLs or CRL sets

  • not clear whether mobile devices use revocation at all

PKI

  • public key infrastructure (PKI) is used for managing public keys, private keys, and their use
elements of a PKI

  • includes all aspects of using public key cryptography, from generation, to bootstrapping session keys, certificates, revocation

  • several challenging elements

    • long term storage of private keys is challenging
      • particularly for individuals
      • critical websites may use offline storage, but many use online storage
      • backup and recovery typically needed
    • revocation (see above)
    • public key distribution and verification for people (websites use the CA hierarchy)

Alternatives to the web model

  • Signal
    • verify public keys using an out-of-band channel
    • most users have no idea this exists or what it is for
signal key verification screens

  • Web of Trust / PGP

    • sign keys of people you meet and verify, perhaps at key signing parties
    • pass these along to your friends
    • decide individually who you trust
      • just those you verified yourself
      • friends of friends
      • friends of friends of friends?
    • generally a failure

  • Trust on First Use (TOFU)

    • accept a public key the first time you get it
    • look for key continuity, e.g. warn users if keys change so they can verify
    • autocrypt appears to be making some progress putting this into open source email systems
    • TOFU is also often used with SSH servers

Class Exercise

  • use Chrome to inspect website certificates

Extra reading