ITS 421 - Tactical Perimeter Defense

Chapter 13, Public Key Infrastructure and Encryption


This lesson discusses Public Key Infrastructure and its security concerns. Objectives important to this lesson:

  1. Functions in PKI
  2. Basic encryption and PKI
  3. Digital certificates
  4. What PKI is and is not


Chapter 13

Functions in PKI

Public Key Infrastructure is not the only code system used in business or government, but it is widely used by both, and by individuals to protect personal or sensitive information. The text points out that there is a difference between PKI and public key cryptography.

  • Public key cryptography is a system in which each entity has two cryptographic keys, each of which is the only means to decrypt what was encrypted by the other.
  • Public Key Infrastructure is a system of using public key cryptography, distributing keys through trusted sources, and revoking keys that have been compromised.

Public key cryptography is a system that uses two encryption/decryption keys. An entity, whether a person or company, must have two keys in this system: a public key and a private key. They are created so that whatever is encrypted with one must be decrypted with the other. The owner of the keys gives the public key to anyone who wants it, but keeps the private key safe from anyone else. This is how SSL encryption on a web site works. I connect to a vendor's web site. I obtain the vendor's public key by making the secure connection. My browser encrypts my credit card data with the vendor's public key and sends the ciphertext to the vendor. If the vendor's private key is secure, the vendor is the only one who can decrypt the data sent through the public key.

That's the way it is supposed to work in a perfect world. However, attackers have created a need for a security net around the process. In a way, PKI is the success story of businesses that have grown up around this technology. The text lists components of public key infrastructure on pages 289 and 290:

  • Certificate authority - An entity, typically a company, that creates digital certificates, which are verified statements of a public key and its owner. They may also create the key pair for the customer, and are responsible for storing and providing certificates as needed.
  • Registration authority - An entity that receives requests for certificates, verifies the requests are from recognized users (such as merchants processing credit cards), and forwards the requests to certificate authorities.
  • Certificate server - A service, or the device that runs the service, that responds to certificate requests.
  • Certificate repository - A database for storing digital certificates, sometimes including records of revoked certificates.
  • Certificate revocation list - A list of certificates that are no longer valid for various reasons.
  • Certificate validation - A process used to make sure that a request submitted for certificate creation actually came from the organization it appears to come from, and that the key submitted in the request is theirs.
  • Key Recovery Service - A service that stores and recovers encryption keys in case they should be lost, for example in a system crash or attack.
  • Time server - A service that provides a standard time reference, used to mark the time of requests and responses. Timestamps may be used to judge whether requests are being processed by the entity we expect to process it.
  • Signing server - In a system that is increasingly automated, this is a central control over related services.
Basic Encryption and PKI

The text moves on to discuss the facts above. Several encryption systems are mentioned on page 291. Some use one key for encryption and decryption, some use two. Single key systems are symmetric systems, and the whole system is worthless if the key is broken by a hacker. Two key systems are asymmetric systems.

The text lists three symmetric algorithms to be aware of:

  • DES - Data Encryption Standard
  • 3DES - Triple Data Encryption Standard
  • AES - Advanced Encryption Standard

It also lists some asymmetric algorithms:

  • RSA - named for its creators, so there is no acronym meaning
  • Diffie-Hellman - also named for its creators; does not seem to belong in this group, since it is only used to allow two users to share a key, enabling them to use symmetric cryptography
  • Elliptic Curve Cryptography - the link takes you to an Ars Technica article that reviews all three methods, and may hurt to read; just know that it exists, and that it predicts the end of RSA within 5 year. The article was written three years ago.

Algorithms use a set of values or characters to create keys and to encrypt messages with those keys. The set of values is the keyspace. Larger keyspaces mean more possible keys from the algorithm. This is what makes it harder to guess the actual contents of a key. Think about that. We rely on secrecy about the algorithm and on the complexity of the keyspace to make security of this type possible. And unless we do something special with the algorithm, most are known, so we only have to know the key and right algorithm to be able to decrypt a message sent in symmetric key system. Are you worried now?

On page 292, the text discusses symmetric systems, and it brings up an interesting point. To address the problem of a symmetric key being exposed, we should consider how many different keys we can make with such a system. We need to switch keys from time to time for security, and we want make sure we have a different key for every user on our system. That is only for communication between each user and the main system. The text explains that this sort of system would also require a different key for every conceivable pair of users on the system, assuming that they all need to communicate securely with each other. The text provides a formula for the number of keys we would need in a system like that: number of users times (number of users minus 1) divided by two. If we had a thousand users, how many keys does that system have to make, just to work for a while? Four hundred ninety nine thousand, five hundred keys. It should be obvious that we also want the system to store those keys and make sure none are repeats. Oh, my.

Moving on to asymmetric encryption, the text explains the text explains public key encryption, as noted above. It seems odd, at first, that a public key can be given to everyone. It takes a moment to get the concept the first time. The keys are created in pairs, and you give your public key to me (or everyone who needs a copy). You keep the private key secret. This enables me (your customers) to send encrypted traffic to you that only you can read. To turn that channel around, you need my public key, so you can send an encrypted message only I can read. It is possible for you to encrypt a message with your private key, and send it to me, but anyone intercepting that message would be able to decrypt it. A message sent to me that way proves you have the matching key, but it does not prove you are who you say you are, unless I trust the method by which I received the public key copy.

The difference between the number of keys needed for secure transmission in symmetric versus asymmetric systems is shown in a table on page 294. Compare the example above (a thousand users) in the two systems. In an asymmetric system we only need two thousand keys. Using an asymmetric system with a large keyspace means we do not have to switch systems just because we increase our user population by a factor of ten, or because a particular key was exposed.

Digital Certificates

On page 295, we see the standard contents of a digital certificate. The most critical factor is the public key, but the other factors are required by the X.509 standard, which the text has mentioned a few times. The link to Wikipedia tells us that X.509 is an international standard for PKI. Some of the elements included in that standard are:

  • 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)

Most of the points on pages 296 and 297 have been discussed. The text also mentions that keys are destroyed when they are compromised and when they reach the end of their intended life. This is more about private keys than public keys. Note that lifetime should be related to the sensitivity of the use the key serves. More sensitive equals shorter life.

This concept is easily confused with the information on page 299 that tells us about certificate revocation. When certificates are compromised (stolen and used by other entities) those certificates are moved to a Certificate Revocation List (CRL) which may or may not be part of the certificate repository.

What PKI is and is not

PKI can provide security, integrity, and nonrepudiation. It is used for financial transactions and downloaded file integrity. PKI is meant to be one layer of security.

It does not include authorization functions. It does not prove the identity of someone who is only using the public key in a key pair.

It also does not prove that someone who has a key pair is trustworthy. Unless you already trust a vendor, the fact that they use a public key pair does not by itself mean you should trust them. The text gives us an example of a vendor who we already trust and respect, and compares that to a vendor we know nothing about. The transaction from each may be trustworthy, but the vendor in each case either deserves our trust or does not.


Assignments for Chapter 13

  1. Complete the Review Questions posted for this chapter in the Review for Test 3, from number 22 through number 32.
  2. Pick one of the case studies at the end of either chapter. Briefly explain what you see as right and wrong about the situation and the solution proposed by the authors. Is there another recommendation you would make?