Teach Me How to Route

Demystifying Cryptography

Many system administrations and network administrators alike find the details behind cryptography rather difficult to comprehend. Prior to me researching and learning about it, I also thought it was rather difficult, but it’s not.

What is Cryptography?

Put rather simply, cryptography is the science of manipulating data in such a way that it is obfuscated and useless to one who does not have the knowledge of the cipher and any associated secret keys to decrypt.

But there’s more to it than that, there are actually three common forms of crytography:

  • Encryption – a method of obfuscating data that is reversible, generally using secret keys and a shared cipher.
  • Hashing – a method used for verifying the integrity of data, not so much for obfuscating data.
  • Steganography – hiding data in plain site, for example in pictures.

History of Encryption

Throughout history, different forms of encryption have been used to hide data for various purposes. Historically speaking, data only needed to be kept secret for a little bit, and during the height of World-War II, the general rule of thumb was that data only needed to be kept secret for about 3 hours.

That’s where classical ciphers come in.

Caesar’s Cipher

The Caesar’s cipher is one of the most well known forms of encryption. The Caesar’s Cipher is a form of substitution cipher wherein letters are shifted three characters to the right in the alphabet.

For Example, if we wanted to encrypt the work “ALPHA”, it would have the following cipher text:

Cipher Text: DOSKD

To decrypt this, we would simply shift each character of the cipher text 3 characters to the left.

For example, the Cipher Text: PRPPD would decrypt to:

Plain Text: MOMMA

As you can see here, we actually experienced a phenomenon common to the English language, certain letters occur throughout our language more often then others. This is something known as Frequency Analysis.

Obviously the padding of three can really be substituted for any desired padding, it doesn’t require much effort to break this either as all you need to know is the padding used to shift characters.

Vigenere Cipher

Similar to the Caesar Cipher, this is another form of classical substituion ciphers. Instead of the shift being a set number of characters, the shift is actually defined by a phrase known as the “key”.

The easiest way to visualize this cipher is through the use of a table that lists corresponding cipher text for each plain text entered.

Vigenere Cipher Table:

For our example, we’ll use the following key:


Now let’s encrypt the word “Dogshow”

Ciphertext: ZCSTHHS

As you can see, our key wasn’t exactly the same length as the word we were encryption, so we actually just end up wrapping around to the beginning of our key when we get there.

Now using that same key, let’s decrypt the following:


Using our cipher, we should get the following:


This cipher was considered unbreakable for over 3000 years, until a method of easily decrypting the data was developing in the 1800s.

Modern Encryption

Okay, we’ve gone a little into some of the most simple ciphers known to man, there are many others that were used throughout history, but it’s time to get into modern cryptography and how we can use that to keep data secret.

Today’s algorithms are based largely on math, and that’s in many thanks to the advancements in computers that allow us to calculate large numbers in real time. Something that would take even a skilled cryptographer years to do.

Stream vs Block

I won’t go to far into this because the goal of this post is to get people comfortable with Cryptography, not make them experts.

There are two well known encryption ciphers that provide the same result, just in different ways. There are Stream Ciphers and Block Ciphers.

What is a block cipher?

A block cipher is an algorithm that encrypts fixed lengths of data, one at a time. This fixed length of data is known as a block, giving the cipher it’s name. The size of each block generally ranged between 64-256 Bits.

What are some common block ciphers?

You probably already know most of them, and maybe just didn’t know that they were block ciphers, but some common block cipers include:

  • DES
  • DES
  • AES
  • Blowfish
  • Serpent

What is a stream cipher?

A stream cipher is an algorithm which encrypts one bit of data at a time. Stream ciphers are designed around the ideal cipher known as a one-time pad. However, the idealism of the one-time pad presents us with too much impracticability for everyday use.

What are some common stream ciphers?

There are probably alot less common to you, these ciphers your really don’t see everyday although some of them, such as RC4, are used for WPA and WEP encryption. RC4

Kerckhoffs’ Principle

Kerckhoffs’ principle is a theory behind cryptography where the strength of encryption should not rely on the secrecy of the cipher, but only the secrecy of the key.

This is visible in just about all modern day encryption algorithms. The cipher is generally open to scrutiny and criticism, which in turns makes it more secure.

However, we keep our keys near to our chest, because without those, our data can’t be decrypted.

And there are some good examples of this. Looking back in history, everyone can probably remember the OpenSSL Heartbleed nightmare. While the vulnerability did allow attacks to slowly leak information about the secret key, it was caught because the OpenSSL library was open-source and easily audit able by anyone in the world.

This is a good example of Kerckhoffs’ principle in action.

Encryption vs Hashing

This is one that I think is pretty simple to understand, but I’ll go over it briefly as it’s an essential component of modern cryptography.

Encryption is based of the original goal of cryptography, keeping data secret. It works in a reversible manner where both the person decrypting and encrypting the data have a secret key they use to perform those actions.

Hashing is different. Although hashing is a form of cryptography, it’s not based on the original goal of cryptography, but is based on the idea of maintaining and validating the integrity of data.

Sure, hashing is often used as a form of securely storing passwords, but hashed data is non-reversible. Hashing operations are performed one way and cannot be performed in the other. Typical authentication methods used hashed and salted data to securely store the password in a database.

What’s salting?

I mentioned salting in reference to securely storing passwords. This is a method where the data is appended with random data before being hashed to prevent simple attacks such as rainbow table attacks on passwords.

A rainbow table attack is where an attacker has a pre-calculated databased of known passwords in there hashed form and attempts to derive the password based on collisions.

What’s a collision?

This is rooted in one of the major concepts behind hashing. Hashing should result in a unique output for each unique piece of data inputted. What this means is that no one word in it’s hashed form should equal the hashed form of another word.

There have been some successful attacks on older, and current hashing algorithms that have resulted in successfully being able to manipulate and produce a collision. The most notable of these that I suggest you research if you want to learn more is SHA-1.


Alright, if you read this one I want to thank you for bearing with me. These are some of the basics behind cryptography that I think are very important to understand if you implement any type of encryption or hashing in your day to day job duties.

If you’re really interested in reading more about this, a book I found extremely helpful when I was studying for my ECES:

Serious Cryptography by Jean-Philippe Aumasson


Posted in PKITagged , , , , , ,

PKI – Part 3 : RDP Certs

Pesky Warning Messages

If you’ve ever found yourself remoting into a machine, you’ve likely encountered that pesky and rather annoying message that the servers certificate can’t be trusted.

We know, you could, you could just select that little checkbox that says “Don’t ask me again for connections to this computer”, but that’s not what we’re going for.

Getting Rid of Self-Signed Certs

We want to use our enterprise PKI to get rid of self-signed SSL certs, and that’s reasonable. Self signed certificates are impossible to track effectively and many systems will refuse to connect to a system with an expired certificate, and that’s good.

While RDP doesn’t necessarily have that issue because it will generate a new certificate when the original expires, it’s something that we could also leverage our PKI to do.

Creating our Certificate Template

This one is a rather simple and easy one for us to do, let’s open the Certification Authority MMC snapin and get to managing our Certificate Templates.

With the Certificate Templates Console open, right click the “Web Server” template and click “Duplicate”.

Open the “Security Tab” and provide the following permissions to the following Active Directory Objects:

  • Domain Controllers: Read, Enroll
  • Domain Computers : Read, Enroll

We set these permissions so that our Workstations, Servers, and Domain Controllers all have the required permissions to request these certificates and have them automatically issued to them.

Like any template, it’s up for you to really specify the rest such as cryptography, extensions, name, etc. For my template I will be using the following:


  • Provider Category: Key Storage Provider
  • Algorithm Name: ECDH_P384
  • Minimum Key Size: 384
  • Request Hash: SHA256

Request Handling:

  • Purpose: Signature and Encryption


  • Name: RDP-Encr
  • Validity Period: 4 years

Something important you probably do need a little assistance with, make sure you modify the “Subject Name” to “Build from Active Directory Information”:

Setting up Our GPO

Unless you have Remote Desktop Gateway Services installed on everything, the only way to ensure that everything uses a specific template is through either the registry or group policy.

Obviously we already know that managing things through the registry isn’t a scalable option. For this we’ll be using Group Policy. To get started, open up the Group Policy Management Console and create a new Group Policy Object.

I’ll be naming my “RDP – Certificate Templates”, the name of this actually eludes the specific setting we are going to be modifying. I hope you remember the name of your certificate template, because you going to need that moving forward.

In the editor for the GPO, Navigate to the following:

Computer Configuration -> Administrative Templates -> Windows Components -> Remove Desktop Services -> Remote Desktop Session Host -> Security 

Once here, locate the settings “Server authentication certificate template”, open it and specify the name of the template we just created.

Once you’ve done this, you can close everything out and link that GPO to your desired location. Since I want everything in my lab domain to have a CA signed RDP certificate, I’m just going to apply it at the root and force a group policy update to demonstrate it real quick.

Before I demonstrate, I’m just going to validate the the server has receied the correct GPO settings via:

gpresult /h <path-to-html-report>

As you can see, the setting is applied as expected. The RDP Service will request a new cert next time I connect and if I use the proper DNS name to connect, I should not receive any errors.

Testing It Out

First, we’re going to test this out to make sure that when I connect, I don’t get a certificate not trusted error.

Other Thoughts

I thought about enabling TLS1.2 on these, but there’s a few issues with that:

  • Not supported in Group Policy, has to be done through registry.
  • There are known compatibility issues with forcing RDP to use TLS1.2, mainly because you have to disable all other version of SSL and TLS.
Posted in PKITagged , , ,

Public Key Infrastructure – Part 1

It’s been over a year since I’ve last posted and that’s primarily because of life smacking me straight in the face. Between studying for college, certification exams, and the recent news of our Baby Girl on the way, I just haven’t had the time to sit down and write a meaningful and well thought out post.

In the months since my last post, I’ve also added some pretty cool certifications to my resume, most of them I actually did within the last month:

  • ITILv3 Foundations
  • CompTIA A+ (I know, really? Part of my degree program)
  • EC Council Certified Encryption Specialist (ECES)
  • ISC2 Systems Security Certified Practioner (SSCP)

Next weekend I’ll be taking the ISC2 Certified Cloud Security Professional (CCSP) Exam, so I should be adding that one to my resume as well. I’m excited and enjoying focusing a lot more on security than networking, the enjoyment I got out of networking had begun to grow stale.

I still find a good amount of enjoyment out of it, but not the amount I used to where I would often find myself up for 3 days straight off of the pure chemical rush of learning and labbing things out.

Turn’s out you’ll wait no more. Today’s discussion will be part 1 of a multi-part discussion on PKI. This post will primarily focus on building a two-tiered PKI infrastructure using Active Directory Certificate Services.

Here’s what the other parts will cover:

  • Part 1 – Building a Two-Tiered PKI
  • Part 2 – Configuring and Setting Up Smart Card Logon and Smart Card based EFS
  • Part 3 – Configuring Automatic Enrollment and Certificate Selection for RDP
  • Part 4 – Federating login with Office 365 and Providing S/MIME functionality with your on-prem PKI
  • Part 5 – Forget Smart Cards; FIDO, TPM VSC and more

Before I get too far ahead of myself I want to make it clear that I’m assuming you already have an understanding of Asymmetric Cryptography and PKI and because of that, I’ll only describe it with three bullet points:

  • Asymmetric Cryptography – data is encrypted with a different key than it is decrypted with.
  • PKI enables functional Asymmetric Cryptography by providing a backend to validate, issue, revoke and publish certificates to a directory
  • In an asymmetric cryptography environment, users have both a private key and public key. Data encrypted with the public key of a user can only be decrypted using that same user’s private key.
  • For Example:
    • Jane wants to encrypt data to Send to Jon; neither Jane or Jon have exchanged private keys to encrypt the data.
    • Jane will instead reference Jon’s public key stored in their local directory. Jane will encrypt the data using Jon’s public key and also sign the data with her private key.
    • When Jon received the data, he will decrypt the data with his private key, and reference Jane’s public key to validate the digital signature.

The above is a simple example of how such encryption would work. There are a few key distinctions made in this example that I want to highlight before moving forward.

  • Digital Signatures can only be signed by the owner of the private key.
  • Digital Signatures are proof of origin, and in some instances provide evidence of non-repudiation.
  • Digital Signatures are validated using the user’s public key.
  • Encryption of data is only possible using the recipient’s public key.
  • The decryption of data is only possible using the recipient’s private key.
  • In either instance, there is a key-pair generated that contains both the private and public keys. Generally speaking, only the user will maintain possession of the private key. Public Keys are normally published to a Global Address List (GAL) or in Active Directory

For our setup, we’ll be using a simple two-tiered PKI for an enterprise environement. There won’t be a whole lot of things going on, but we’ll show you how to get this setup and working in your environement. The two Certification Authorities we’re going to be creating are:

  • Scorchedwire Media Group – Root CA X1
  • Scorchedwire Media Group – Subordinate CA G1

Based of the names, I’m sure you’ve already made the assumption that there’s some heirarchy here to this setup. This is normal in any PKI.

  • The Root Certification Authority is responsible for issuing certificates to Subordinate Certification Authorities.
  • The Root CA should remain off at all time, other than to patch, manage certificates (issue/revoke) and to periodically publish CRLs.
  • The Subordinate CA will be used to manage all server and user certificates, not including CAs.
  • The Subordinate CA will publish the Root CAs CRLs.

Wait, you mentioned CRL, what’s that?

When a CA revokes a certificate prior to the expiration, a new entry to the servers Certificate Revocation List (CRL) is created. The CRL is what provides systems with the information necessary to establish whether the certificate is valid or not.

Let’s Get Started

To start, I’ve already deployed to Windows Server 2016 Standard VMs. When deploying these VMs, here’s the setup you should use:

  • The Root CA should be offline, and not domain joined.
  • The Subordinate CA should be online, and domain joined.

Installing ADCS

The first task we’re faced with is actually installing ADCS on both the Root and Sub CA. This is relatively easy and can be done through the server manager, under Add Roles and Features.

Additionally, if you’re not one for GUIs or your Root is running Server Core, you could use Powershell.


Anyway, time to get started on the Root CA:

Open the Server Manager, navigate to Add Roles and Features. Navigate to the Role-based or feature based installation and click next.

You’ll find a screen for “Active Directory Certificate Services” , select this and accept the popup asking you to install the management tools as well. You’ll want these for configuring AIA and CRL publication locations.

Go through all the steps, just clicking next. Ensure that when you get to “ADCS -> Role Services” that the only selection is “Certification Authority”, click next and click “Install”

Once the role is installed, there’s a couple things that need to be completed.

  • Configure the Root CA, and generate a Certificate
  • Configure the Root CAs maximum validity period.
  • Configure Root CA AIA and CRL Publishing locations
  • Last, issue a certificate for the Sub CA once we’re complete with the setup there.

You’ll probably notice in the Server Dashboard that there is that notorious yellow caution icon, let’s click that and get to configuring our certification authority.

Some things I think you can do without me showing you pictures, hopefully:

  • Specify credentials, click next.
  • Select Role of Certification Authority, click next.
  • Select “Standalone CA”, click next.

Next up, we need to generate our private key, to do this select “Create a new private key”, and click “Next>”

So what about these crypyography options?

Honestly, that’s all on you and your business requirements. I personally prefer Elliptic Curve to RSA, so I’ll be creating my Certificates with ECC where possible, when we get to smart cards, we’ll have to deal with RSA. I’ll put an section in for my general preferences and recommendations at the end and why I make certain choices.

For my options, I’m selecting

  • Cryptographic Provider: ECDSA_P384 Mcirosoft Software Key Storage Provider
  • Key Length: 384
  • Hash Algorithm: SHA384

In the Next Window, I’m only going to specify my Root CA name.

Lastly, the validity period. This is really contingent on your needs, but Root CAs can be valid as long as you feel confident in the encryption and protection mechanisms behind them.

Obviously public and government CAs have guidelines and regulations they have to follow, but for enterprise CAs, that’s really a business decision based on the risk. I recommend no longer than 15 years.

Next up we’ll specify where we want the certificate database and logs to be located. I’m going to move them from the default location to a seperate location. The default location is “C:\Windows\System32\CertLog”

Next up, just verify the options you selected and click “Configure”.

Once, you get it configured, you’ll get a message stating success, let’s move on to the next part.

Configuring Maximum Issuance Lifetime

For those of you familiar with certificate requests, you’re familiar with the fact that you usually specify the desired certificate lifetime in your request. While this might seem like it’s what actually dictates how long your certificate is valid for, it’s actually something else.

Open the registry editor and navigate to the following registry hive:


There are two registry values you may need to edit, these have to do with validity period of issued certificates.

The first one is the only one we will be editing, since the default value for the other one is already set to years.

Key Name: ValidityPeriodUnits
Default Value: 1
We're changing it to: 10

The other one you might want to change, depending on your configuration is:

Key Name: ValidityPeriod
Type: REG_SZ (String)
Default Value: Years

Configuring AIA and CRL Publishing Locations

Open the Certification Authority MMC Snap-in and point it to your CA if it isn’t already.

Right click on your CA name and click “Properties”, open the “Extensions” tab.

I’m going to need to delete all the default entries for CRL Distribution Points and AIA:

Next up I’m going to want to specify the locations that these are stored locally, for this I’m publishing them to the “C:\Certificates\DB” folder.

CDP: C:\Certificates\DB\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
AIA: C:\Certificates\DB\<ServerDNSName>_<CaName><CertificateName>.crt

Next up, I’m also going to specify where they will be published on my Subordinate CA. I will have to manually import these, but they’ll be published using an IIS site on my Subordinate CA.

The location for this will be:

CDP: http://ocsp.scorchedwiremedia.net/certs/CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
AIA: http://ocsp.scorchedwiremedia.net/certs/<ServerDNSName>_<CaName><CertificateName>.crt

You’ll notice that I selected a few check boxes, make sure you check all of these. Some of these are just for the sake of beauty when pulling up “pkiview.msc”, the others are actually important for telling clients where to look for new CRLs.

Next up, you’ll click “Apply”, and the service will restart.

One more thing we’ll want to do before we continue is set the CRL interval for when CRLs will be published. Since the CA is offline, I’m going to set the CRL publishing interval to every 52 weeks, I’ll have to turn this on next January to publish a new CRL.

To do this, drill down to revoked certificates in and right click “Properties” and set the interval to “52 weeks”, you can also set this higher if you really want to, no need to publish delta CRLs since we won’t be online often enough.

Now, right click the “Revoked Certificates” and click “Publish CRL”, go grab the CRL from the file location on the local disk and export this to a place you’ll remember for later, we’re going to need this when setting up the Subordinate CA.

Setting up the Sub CA

Time to move on to our Sub CA Server. We’ll be going through and installing AD CS on that too, but I won’t go through the pictures on that part until we get to the configuration. The following roles should be installed on your Sub CA, which should be domain joined:

  • Certification Authority
  • Online Responder (we’ll use this in another part of this series, so just install it for now)
  • IIS – for publishing CRLs, for now.

Optionally, you can install the Certificate Enrollment Web Service, which provides a web interface for users to enroll in and request certificates. Since I use the Certification Authority MMC Snapin, I don’t see a need for this as most times we will be enrolling on behalf of other users or users will be automatically enrolled through AD.

Now that it’s installed, the first thing I’m going to do is create an IIS site for the CRLs and Certificates. First I’m going to create the directory “C:\certs” and copy the CRL from my Root CA here then I’m going to create a virtual site for this in IIS Manager.

  • <SERVER-NAME>\IIS_USRS should have read only access.
  • NETWORK SERVICE should have read only access.
  • Authenticated Users should have read only access.

In IIS Manager, I’m going to right click the Default Web Site and select “Add Virtual Directory”, the virtual directory name will be “certs”, pointed to the physical directory “C:\certs”

I’ve also enabled directory browsing so I can navigate to the website and validate the certs and CRLs are there:

Now, in my browser I will validate that the Root CAs CRL I placed there can be reached

Now that we’ve setup all the pre-requisites for our Subordinate CA to validate these CRLs, it’s time to configure our Sub CA:

Go back to the server manager and get rid of that pesky yellow caution icon, it’s time to configuration ADCS.

Again, somethings you can do without me:

  • Enter Credentials, click next.
  • Select “Certification Authority”, click next.
  • Select “Enterprise CA”, click next.
  • Select “Subordinate CA”, click next.
  • Select “Create a new private key”, click next.

Select the cryptography for this one, I’m going to use the same I used on the Root CA:

  • Cryptographic Provider: ECDSA_P384 Mcirosoft Software Key Storage Provider
  • Key Length: 384
  • Hash Algorithm: SHA384

The Common name for this CA will be “Scorched Wire Media Group Subordinate CA G1”

Click next, save the Certificate Signing Request (CSR) to the local disk, copy to a location that you will remember as well, we’ll use this to request the Certificate from the Root CA.

Click next, select where you’re going to save the certificate database to, and click configure.

Issuing our Sub CAs Certificate

Now that we’ve generated the request, lets take that and copy it to our root CA server. On the Root CA server, open up the Certification Authority MMC Snap-in.

Right click on your CA, select “All Tasks”, and “Submit New Request”

Select the CSR from your Sub CA, refresh the “Pending Requests” tab, and right click your request and select “All Tasks”, click “Issue”

Next, go to the “Issued Certificates” tab to locate your Sub CA’s certificate. Click “Open”, navigate to the certificate details and select “Copy to File”, use the certificate export wizard to export the public key and copy this to your Sub CA.

Installing the Public Key on Our Sub CA

Next go back to our Sub CA and open up the Certification Authority MMC Snap-in. You’ll notice that the services aren’t started, and that’s because we haven’t installed our certificate yet. Right click your CA Name and select “All Tasks” and click “Install CA Certificate”, in the popup, navigate to and select the certificate you exported in our previous step.

If you exported the certificate in a format that includes the Root Certificate, you should not have any issues with the CA Services starting on your Sub CA. If you get an issue saying that the certificate signature cannot be validated, this is because the Root Certificate needs to be installed in the Trusted Root Certification Authorities certificate store.

Next up, make sure you export the Root Certification Authorities Certificate in the format specified in the AIA locations. If all is done correctly, you should be able to open “pkiview.mmc” and see no errors.

You made it this far:

You made it this far, so you should know a few things that should be done moving forward:

  • Cleanup CRL and AIA distribution points on the Sub CA, there’s some defaults that just need to be removed to avoid issues later.
  • Since the Sub CA is an enterprise CA, all CRLs are already published to Active Directory, so no need to publish them to the IIS virtual directory unless you want to.
  • Think deeply about the cryptography used. Using next-generation encryption where possible will save us all when computing power eventually get’s powerful enough to break RSA 2048-bit keys.
  • If your Root CA is in a production environment and used for actual enterprise certificate services, consider full disk encryption to protect against simple methods used to steal the CAs private key.
  • Consider migrating your IIS to HTTPS once your have your CA setup, if you’re like me, you encrypt everything (even DNS), because you’re paranoid.
  • You’ll notice I’m using the DNS name ocsp.scorchedwiremedia.net, that’s because one of our future updates to this series will cover setting up an online responder for Smart Cards and S/MIME.
  • When we modified the validity period, we didn’t actually specify the validity period of specified certificates. The validity period is actually determined as the intersection of the shortest period between the configured validity period and that on the Signing Request. Therefore, if a CSR requested a cert that would last 5 years, but the CA was only configured to issue certs for 2 years, the cert validity period would be 2 years. On the flip-side, if a CSR requested a cert that was 3 years, but the CA was configured for 5 years, the cert issued would be valid for 3 years.
  • Don’t forget to update the configured validity period on your Sub CA, otherwise all your Certificate Templates will be ignored for validity periods when certificates are issued using them.
  • Don’t forget to harden your CAs, you don’t want them to be breached because you forgot to do your due-diligence.
  • Don’t forget to publish your CA certs to domain joined computers. The easiest way for this is just a Group Policy that publishes the Root CA to the Trusted Root Certification Authorities certificate store and the Sub CA to the Intermediate Root Certification Authorities Certificate Store.

Here’s a good table on the effective strength of ECC vs RSA:

Credit: https://www.globalsign.com/en/blog/elliptic-curve-cryptography/

Posted in PKITagged , , , ,