Introduction

Greetings programs!

This is the first post in what will be a 3 part series on PKI for network engineers.  The objective of the series is to give a high level overview of the technology, create a basic build using Windows active directory, then use the PKI to do some useful things.

I’m not going to go in-depth on any of the topics, nor is it going to be a basic click-by-click walk-through.  My intention is to seek a middle ground where the reader can with a minimal investment in time and effort, build their own pki and use it, understanding the fundamentals of how it works.  I’ll reference suggested reading if you would like to go deeper into a given topic.

What is a PKI and what is it good for?

PKI is an acronym for Public Key infrastructure.  It provides a salable means of requesting, creating, distributing, validating, and revoking digital certificates.  There are public PKI providers such as Verisign, Network solutions and Godaddy, but these are very expensive and you would normally limit their use to services offered over the public internet.  For organizational and personal/labbing use, it makes more sense to create a private, self administered PKI.

Practical uses of private PKI:

• Validate the identity of intranet sites and applications to users and other applications
• Identify and Authenticate devices and users for access to:
  • wired networks
  • wireless networks
  • Virtual private networks
• Machine to machine authentication
  • IPSEC VPN
  • FLEXVPN
  • DMVPN

Think of a digital certificate as a passport.  It has all sorts of useful information in it, and the passport comes from a trusted authority.  With our own PKI, we can define what information to put certificates, and we can with the help of windows active directory, deploy the certificates to large numbers of devices, services, applications, and people in an automated fashion.

 

Cryptography basics

Before we go any farther, we need to review some cryptography basics.  I’ll try to make this brief.  If you want more details, check out the suggested reading at the end of blog post.

The goal of cryptography is to provide 3 services to it’s users: Prove data has not been modified, keep it secret, prove the identity of the sender.

Here’s a pattern outline breakdown that associates these services with the tools that provide them.

• Integrity
  • Guarantee that the information has not been tampered with
    • Provided by hashing algorithms
• Confidentiality
  • Making information private
    • Provided by encryption algorithms
      • Typically uses symmetrical keys securely exchanged using an asymmetric key pair
• Authenticity/non-repudiation
  • Verifying the identity of an entity or the identity of an information source
    • Digital signatures
    • Asymmetric key pairs

Encryption Types

There are two types of encryption used in PKI, symmetric encryption and asymmetric encryption.

Symmetric encryption is straightforward.  Both sides of use the same key to encrypt and decrypt information.  Because this is the fastest type of encryption, it’s typically what’s used for bulk data (such as a webpage encrypted with TLS).

Symmetric Encryption

Common Symmetric encryption Algorithms include:

Data Encryption Standard (DES) (and 3DES)

Rivest’s Cipher Version 4 (RC4)

Advanced Encryption Standard (AES)

While I’m not going to go into the details of these algorithms, it’s worth noting that DES is insecure and outdated, and 3DES is computationally expensive because it takes multiple passes.  AES however can do single pass encryption with up to 256 bit keys, making it the encryption algorithm of choice for VPN and other bulk data applications.  I recommend kicking DES/3DES to the curb and using AES as the default for your VPN configurations.

 

Asymmetric encryption is quite a bit more complex (and computationally expensive).  It uses two mathematically related keys for the encryption and decryption process.  These are public and private keys.  If one is used to encrypt information, it can only be decrypted with it’s counterpart.   The public key can be distributed to anyone, and the private key should be held and used only by it’s owner.

 

Asymmetric Encryption

In this example the following happens

1. The owner of a private key encrypts a document with her private key
2. The recipient receivesthe documents along with a digital certificate with the public key
3. The recipient tests the certificate for validity
   1. Is the SHA thumbprint correct
   2. Is the certificate expired?
   3. Does it chain back to a trusted root certificate?
   4. If the Authority information access valid?
   5. Can I retrieve the Certificate revocation list from the location in the CDP extension of the certificate?
      1. If so, make sure the certificate is not revoked
4. The recipient decrypts the cipher text with the public key

Note that this process can and often works in the reverse, i.e. A message can be encrypted with the public key and then decrypted with the private key.

 

Because the process is computationally expensive, Asymmetric encryption is not used for bulk data.  It’s two most common uses are:

1. Secure exchange of symmetric keys
2. Digital signatures

As you might surmise asymmetric and symmetric encryption are often combined. If you want to know more about how that works, check the end of the blog post for suggested reading.

Ok, so now we’re providing authenticity and secrecy, but we’re not proving that the data hasn’t been modified.   Enter the cryptographic hash.

Hashing and Digital Signatures

Hashing algorithms have been an essential part of computer science since the beginning.  You many know them by another name:  the checksum.  The idea is to take data and run it through an algorithm that generates a mathematical result.  That result is called a hash.  Any change, even one bit, would change the product of the algorithm and produce a different hash value.  In this way it can be mathematically proven that the data has not been modified.

The most commonly used algorithms in cryptography are:

Message Digest 5 (MD5)

Secure Hash Algorithm 1 (SHA1)

Secure Hash Algorithm 2 (SHA2)

Please note the following: MD5 is no longer considered secure, and as of January 1 2017 a number of large companies including Microsoft will be deprecating the use of SHA1.  It strongly recommended to use SHA256 or greater in the creation of digital certificates.

A digital signature is the hash value of a text file that has been encrypted with the private key of the sender.  In this manner both the identity of the creator and the integrity of the file can be proven.  It is important to note that the file itself is not encrypted, only the hash.

Ok, this concludes our cryptography review.  Now, we’re going to take an overflight of PKI.

PKI Basics

Digital Certificates

Digital certificates are the foundation of PKI.  They’re digitally signed documents that operate like a passport of sorts.  They can be issued to People, Computers, tablets, phones, routers, switches, applications, or services.  Digital certificates are issued by a Certification Authority (CA).

The typical digital certificate includes:

• Information about the entity the certificate has been issued to.  This is called the subject.
• Information about the issuing Certification Authority
• The public key from the public/private key pair
• The cryptographic suites supported by the certificate
• Validity and revocation information
• Extensions in the certificate. Common extensions include
  • Authority information access (AIA)
  • Certificate Revocation List (CRL) distribution points (also called CDP)
  • What purposes the certificate can be used for (key usage)
  • Subject Alternative Name (SAN)
  • Basic Constraints

x.509 v3 fields.  Image Credit: Windows server 2008 PKI and certificate security

Certificate Revocation Lists (CRL)

All certificates have a validity period, which means they have an expiration date.  But what if a certificate is issued to an employee and they leave the company?  Revocation is a key feature of digital certificates, and a certificate without valid CRL information will not be trusted by most modern applications.

It’s critically important to ensure that the CRL distribution point (or optionally Online Responder) is accessible to all users of a PKIs certificates, or those users will receive errors.

Certification Authorities

A certification authority is…well the name is the recipe right?.  So what does it do ?

• Processes certificate requests
• Issues certificates
• Manages certificate revocation

Certification authorities are typically implemented in a hierarchy.  For most private organizations, a two level hierarchy of an offline root and one or more subordinate issuing CAs are adequate.  Larger or more complex organizations implement a three layer hierarchy that consists of the root, intermediate, and finally the issuing CAs.

Typical 2 tier hierarchy

While it’s certainly possible (not to mention super easy) to make a root CA an issuing CA, it’s highly inadvisable in a real world deployment.  Besides the inevitable scaling issues,  It’s important to understand that the trustworthiness of all the certificates issued in a PKI hinge on the security of the private key of that root CA.  If the root CA were to be compromised and the private key stolen it would be a disastrous, with potentially grave implications for any organization that relies on it.

An attacker with the private key of the root CA in his possession, could use that private key of the root to create their own CAs, or heck, issue whatever certificates they want.  Every device that trusts that root now trusts the attackers bogus certificates.  If an organization has a large number of certificates issued via that trusted root and those certificates are an integral part of business operations, this is not an easily rectifiable situation.  It’s not just a matter of replacing certificates.  An entirely new PKI would have to be rolled out and the compromised root certificate removed from all devices.

For the reasons states above, *any* production PKI should use an offline root.  Never use the root to issue certificates, ever.  It’s worth the extra 60-90 minutes to set up an issuing CA.

 

This concludes part 1 of PKI for network engineers.  In part 2, we’re going to build a PKI and test it.

 

Suggested reading:

Windows Server 2008 PKI and Certificate Security

PKI Uncovered: Certificate-Based Security Solutions for Next-Generation Networks

https://www.safaribooksonline.com/library/view/pki-uncovered-certificate-based/9781587059339/