ITS 2110 - Introduction to Network Security

Chapter 4 - Advanced Cryptography and PKI


This lesson continues our discussion of cryptography. Objectives important to this lesson:

  1. Digital certificates
  2. Use of digital certificates
  3. Public Key Infrastructure
  4. Key management
  5. Transport protocols

Chapter 4 continues the discussion of cryptography. On page 152, it turns to the topic of digital certificates. As discussed above, it can be based on the public key system, but it has a problem. Consider the discussion in the text of the way it should work: If you and I both have public and private keys, I can encrypt something with my private key that you can decrypt with my public key. Anyone else could decrypt it as well, but this step proves that the encrypted form came from me, or at least from the person whose public key you have.

In the example in the text, I can send a message to you encrypted with your public key (which only you can decrypt) along with a hash made from the message and encrypted with my private key. The encryption of the hash proves that it came from me: you can decrypt it with my public key. The hash itself will match a hash you can make from the decrypted message, proving that it has not changed. This is a secure system as long as our private keys remain private, and our public keys are not available except by a secure method. As the book explains, the system fails if you think you have my public key, but you really have the key of an impostor who sent the message in the first place. In other words, you know that the message is unchanged since it left the person who sent it, but how can you be sure that it came from the person you think it came from? How do you know my public key is really mine?

You need to get my public key from a trusted source, like Verisign, which is now affiliated with Symantec/Norton. If I register my public key with a trusted source (typically a certificate authority), or have them create it in the first place, they provide me with a copy of the key that is endorsed by them, which makes it a digital certificate. When I send this certificate to someone, they can verify that it is from an authority that can be trusted. Note the properties of a digital certificate listed on page 154:

  • name or alias of the public key owner
  • public key
  • name of the certificate issuer
  • digital signature of the issuer
  • serial number of the certificate
  • expiration date of the certificate (technically, not of the key, but they may be the same)

This leads us to an industry that supports verified identities by the use of digital certificates. Some terms associated with it:

  • certificate authority (CA) - an agency that issues digital certificates; the CA may create key pairs for users or accept them from users who create them; the CA is responsible for verifying the identity of the key owner; organizations with the proper software can act as their own internal CA
  • registration authority (RA) - an entity that takes on some of the tasks of a CA and operates on their behalf
  • certificate revocation list (CRL) - a list of certificates that are no longer valid for various reasons
  • certificate repository (CR) - a public directory of valid certificates; may contain invalid certificates as well or may link to a CRL

The text moves on to discuss different types of digital certificates.

  • personal digital certificates (class 1) - for individuals to use as needed
  • server digital certificates (class 2) - for web servers, mail servers, and other type servers to confirm identity of the operator; also used by servers to confirm secure SSL sessions
  • software publisher digital certificates (class 3) - to confirm data integrity of published software
  • X.509 - a standard defined by the ITU; features are listed in the text

The certificates described so far have been single-sided, which means they only confirm identity. Dual-sided certificates are actually two certificates: one to confirm identity (signing certificate), and the other to confirm encryption (encryption certificate).

Public Key Infrastructure

The Public Key Infrastructure is the system (or a specific system) that includes all the concepts listed so far in this chapter.

Trust Models

The text lists five trust models, but discusses three of them. One that is only mentioned is the web of trust, which is the model that would exist without any Certificate Authorities. The text describes this situation as one in which all entities know and trust each other directly (direct trust). The other models involve third party trust, in which Certificate Authorities are used.

  • Hierarchical Trust Model - one CA (the root) grants all certificates with a single key, and all entities in the system trust it; there is a single point of failure and all work falls on the one CA
  • Distributed Trust Model - multiple CAs exist; a CA can delegate certificate duties to other CAs; a single failure will not break the entire system
  • Bridge Trust Model - a model that is actually a hybrid of the other two; a bridge CA links CAs in the other kinds of models

Managing PKI

The text describes three concepts to manage the PKI entities better. More acronyms to recognize.

  • Certificate Policy (CP) - a set of rules that dictate what the CAs, RAs, and other entities must do to operate
  • Certificate Practice Statement (CPS) - if a CP is a set of rules, a CPS is a set of procedures for implementing those rules; the CPS states how entities request and perform services
  • Certificate Life Cycle - certificates should have a planned creeation and removal process, so this concept addresses four life events for a certificate:
    • creation - includes the procedures to follow to verify identity, grant and issue a certificate, and publish a certificate
    • suspension - when a certificate should go out of use temporarily, the suspension process is used
    • revocation - when a certificate is found to be invaalid because it has been compromised, the owner is out of business, or for other reasons, the certificate is revoked and moved to the CRL
    • expiration - the normal end of a certificate's lifee; one might wonder if this is to sell the owner another one, but it is also sensible to end certificates regularly in case they have neither been suspended nor revoked but should have been and the CA knew nothing about it

The text continues with a discussion of the care of keys used in PKI. Three concepts and more subconcepts once again:

  • Key storage - the text recommends storing public keyys in digital certificates, or on hardware devices from the CA; it recommends storing private keys on hardware like smart cards or tokens, since they can be vulnerable to attackers when left in file storage
  • Key usage - this concerns how to use multiple key pairs to maintain as much security as possible
  • Key handling procedures - this is similar to the life cycle conccept for certificates; it could have been called a key life cycle but it is called key handling instead
    • escrow - a third party, such as a CA, holds the keys
    • expiration - keys expire so that a stolen key is not good forever
    • renewal - this is an extension to the life of a key about to expire; this invalidates the security aspect of expiration
    • revocation - turning off the functionality of a key before the expiration date; there is no reinstatement from this
    • recovery - although it is not listed as a handling method, a key can be archived, and removing it from that status is recovery
    • suspension - a temporary status to remove the key from use
    • destruction - a permanent status that erases the infformation about the key and the user from the CA, which is not done for expiration or revocation
Cryptographic Transport Protocols

The last major concept for the chapter discusses types of protocols associated with encrypted data flowing across a network:

  • File Transfer Protocol (FTP) - FTP does what it sounnds like, it moves or copies files in a TCP/IP environment; the text describes its problem: no encryption, which makes it vulnerable to man-in-the-middle attacks
    The text recommends using a secure protocol instead when updating web sites or moving sensitive data. Secure FTP (SFTP) can use either of the next two protocols as a basis.
  • Secure Sockets Layer (SSL)/Transport Layer Security (TLS) - You have probably used SSL every time you have made a purchase across the Internet. The vendor site sends a public key to your computer, your computer encrypts the transaction, and the resulting SFTP data stream can only be decrypted with the vendor's private key. (You should know this concept very well by now.)
    The text explains that TLS is an improvement over SSL. This link goes to a Wikipedia article that discusses the same point, as well as the uses of TLS which include email.
  • Secure Shell (SSH) - SSH is another method used to implement SFTP. This is a Unix based protocol, that can be used to replace Telnet, and it is used to provide secure login, file operations, and command line operations on the remote server.
  • Web protocols - such as HTTPS and SHTTP, provide SSL versions of HTTP. Note the discussion of ports: HTTP typically uses port 80, while HTTPS typically uses port 443.
  • IP Security (IPsec) - IPsec is described as a preferred protocol because it is implemented at a lower layer in the ISO network model (Network layer) than PGP (Application layer), Kerberos, or SSL (both at the Session layer). As such, it is more transparent to processes that occur at higher layers, to users, and to software running on the workstation. The text discusses the virtues of IPsec for several pages.
  • S/MIME - uses digital certificates to protect email. This protocol is built into most email applications.