Teach Me How to Route

PKI – Part 2 : Smart Cards

I began writing this one shortly after I wrote my last. As of current, it’s the 11th of January at 1AM and I can’t find the care to go to sleep. Looking back at past posts I noticed that I seem to post these in waves when I get the motiviation.

Typically I’ll spend anywhere from 2-3 hours planning these our and another 2 hours actually writing them. I’m not exactly the greatest wordsmith so I constantly find myself with writers block trying to find out what words go next on the page.

I also try to write my posts in such a way where both the lab and the material are useful. Even if one doesn’t necessarily completely understand the topic, I aim to provide enough information so they aren’t lost in the sauce. Sometimes I execute this better than others. Sometimes I’ll even find myself going to far in depth and loosing myself in the sauce.

Think with your dipstick, Jimmy.

Okay, I get it, I often ramble on for too long to preface these posts, but today we’re going to be talking about something I hold near and dear to my heart, and that just happens to be Smart Card Logon. Those of us with experience in the public sector or military already know what these are and often times how much of a pain they can actually be.

But from an authentication perspective, they’re about as bullet-proof as you can get without exponentially increasing the costs of your infrastructure.

And that’s the focus I take. Industry certifications focus on reducing the risk involved with our systems to acceptable levels, but I don’t quite think that cuts it. Our focus should really be on reducing the ROI for attackers. Sure, there are always going to be well finances groups backed by large organizations and states, but the majority of attacks are actually performed by the lowest of hanging fruit. Low hanging fruits are always looking for the easiest for us to pick by decreasing their ROI from attacks. Anyway, coming back from my tangent. I still don’t get where I was going with that. I’ll probably never know.

Back to Smart Cards.

One of the most prevelant attacks in the industry is credential theft and credential stuffing. This is because of the inherint weakness of username and password based authentication. This is caused because of:

  • Poor credential hygene.

We get it, users don’t want to be bothered with creating complex passwords every three months, but we also don’t want to let them use the same complex password forever. Re: eBay.

We’ve come along way in that we can supplement this with multi-factor using one-time passwords, but those aren’t bulletproof either. in your organization wants to be forced to use a Yubikey, no one wants to be forced to install an app on their phone, no one.

And that’s understandable. This often leads to users enrolling into multi-factor authentication using their phone number, and don’t even get me started on that.

That’s where smart cards can provide us with something.

Everyday, we badge in and out, we don’t think about it, we just do it.

We already have an ID that provides us access to physical locations, why not make this the same thing that gives us access to electronic systems?

Anyway, here’s how smart cards work from an authentication perspective:

  • Users are provided a private and public key pair for the special purpose of Smart Card Logon.
  • These private key is loaded onto a physical token, most often in the form of an ID card using PIV compliant chips.
  • These private keys are protected with a PIN that only the end user knows, which is required to perform signing operations with this key.
  • When a user authenticates using a smart card, they are essentially signing an authentication request using their private key, this is validated against their public key which is published to Active Directory.

What do I need to get this setup?

To get started, you’ll need the following:

  • An Enterprise Certification Authority, see Part 1 of this series.
  • A Smart Card Reader.
  • A Smart Card, or PIV Compliant USB Token.

For my setup, I chose some stuff that’s readily available on Amazon, although if you’re subject to supply chain regulations, you might want to work with a more reputable vendor:

  • PIVKey C910 Smart Card
  • HID Omnikey 3121

Links for these will be provided at the end of the post.

A sad day in history.

Unfortunately, most of the commercially available smart cards only support RSA Keys with a maximum length of 2048 bits. So if you were hoping to use ECC, you’ll be dishing out probably at least triple the money for each card.

Configuring Certificate Templates

The first thing we’re going to need to do before we get any further is configure some Certificate Templates on our CA. To do this, open the Certification Authority MMC Snap-in and right click certificate templates, click “Manage”

We’re going to create two certificate templates here, and lets discuss those real quick:

  • A Certificate Registration Agent, used for enrolling on behalf of other users.
  • A Smart Card Logon, used for actual smart card logon.

I know what you’re going to say, these templates already exist, why can’t I just publish them and use them?

Well, you don’t want to.

First off, the Smart Card Logon does not allow you to enroll on behalf of by default, and second off all of the included templates are configured for older devices such as Windows Server 2003 and Windows XP. We need to get these updated so they support some of the newer features.

Smart Card Template

To get started, right click the “Smart Card Logon” template and click “Duplicate”

In the first window labeled “Compatibility”, Select the operating system of the oldest CA in your environment, as well as the oldest operating system in your environment. My Lab environment is all Server 2016 and Windows 10, so I’ll be going with the newest stuff available for me.

Next up, navigate to “Request Handling”, change the following:

  • Purpose: Signature and Smart Card Logon
  • Check: Allow Private Key to Be Exported

The reason we want to enable the private key to be exported is simply because when we’re creating these, we’ll be creating them on behalf of other users and will need to export the private key to the smart card in order for all of this to work properly.

Next up, go to “Cryptography”, change the following items:

  • Provider Category: Key Storage Provider
  • Algorithm Name: RSA
  • Minimum Key Size: 2048
  • Request Hash: SHA256

You don’t have to follow these exactly, but these are just what I’ve validated to work, and what I’m configuring in my environment.

Next, navigate to “Issuance Requirements” and change the following:

  • Check: This number of authorized signatures (1)
  • Policy Type Required in Signature: Application Policy
  • Application Policy: Certificate Request Agent

These configurations are what is actually going to allow us to enroll on behalf of other users. We’ll later issue our self a certificate with this application policy so we can sign these requests and issue certificates for other users.

Next, navigate to the “General Tab” and give your template a name, I’m naming mine “Smartcard – Managed Enrollment” since I’ll be managing the enrollment of other users with this template. Next, specify the validity period and check publish the cert to AD.

Certificate Request Agent Template

Next up, create a duplicate of the Enrollment Agent template. Following the same steps to setup the cryptography, compatibility, and create the template.

I won’t show pictures from this, just follow the general guidelines doe the Smart Card one, do not do the following though (unless you have bigger plans):

  • Don’t configure the Issuance Requirements
  • Don’t configure request handling

A note here, if you’re not going to store this on a smart card and only plan on storing it in your local certificate store, you can use ECC. Also, if you do plan on using a smart card for this, make sure you make the private key exportable.

Next up, it’s time to publish these to AD so we can use them. To do this, go back to your Certification Authority, right click the Certificate Templates and select “New”, click “Certificate Template to Issue”

Find the template you created and click “Ok”, do this for any templates you have created. Next, verify that these are published. Depending on your account permissions, you may need to go back and change the permissions on the templates. I’m using my Domain Admin account here so there’s no requirement for me to change anything. When it comes to issuing and enrolling in these, I’ll just elevate my session.

Issuing Certificates

Now comes the time to actually enroll and issue certificates. First off, we need to enroll ourselfs in the Certificate Registration Agent certificate we created, to do this open MMC and add the Certificates snapin. If you’re like me and doing this from your normal user account, you’ll need to elevate to admin to do this properly.

In the snap-in, right click, select “All Tasks” and click “Request New Certificate”

If you haven’t already, make sure the computer you’re using has the new Root CA certificate installed in it’s trusted stores, otherwise your computer won’t see any templates you can request.

Since we’re given the permission to enroll in this, all we need to do is click “Enroll”

Next up, let’s enroll my normal user account for Smart Card logon. To do this, right click and select “Advanced Operations”, click “Enroll on Behalf of”

Next, you’ll be asked to select a certificate to sign the request with. Choose the Certificate Registration Certificate we just issued.

Click “Next”, select the certificate we wish to enroll another user in

Click “Next”, now we need to select the user we want to enroll. Be sure to change the default location from your location enrollment workstation to the AD Domain the user resides in. For some reason it always select the local computer.

Next up, click “Enroll”, once complete you will receive a success message (hopefully), you can either select another user or click close.

Now that we’ve enrolled that user, right click their certificate and click export. Ensure that you export the private key as well, remember where you saved this as we’ll need it later to load onto the card.

Setting Up the Smart Card

Before we go too much farther, first make sure your smart card is in hand and your card reader is plugged in.

Once you’ve done that, download and install the PIVKey admin tool from Taglio: http://pivkey.com/download/pkadmin.zip

Once installed, we’ll also need to modify the following registry entries:

Registry Hive: HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft Smart Card Key Storage Provider
Key Name: AllowPrivateExchangeKeyImport
Value: 1
Key Name: AllowPrivateSignatureKeyImport
Value: 1

The reason for this is that Windows doesn’t by default allow us to import private keys to a smart card, modifying these registry values allows us to do so without issue.

Next up we need to delete the existing keys, if any from the card. If you bought the card on Amazon or in quantities of less than 25, it probably has the Default PIVKey certificate on it.

Open Command Prompt as Administrator, when prompted for a PIN type the default pin of “000000”. I’m going through this process to show you how to delete certificates off the card, but I’ve already deleted the default one and loaded my own, so I’ll just delete my own.

Type the command:

certutil -scinfo

You will be looking for the Key Container ID, this will look something like this:

Now that you’ve got that, you can issue the command with certutil to delete the key container from the device:

cerutil -delkey -csp "Microsoft Base Smart Card Crypto Provider" <cert-id>

When done correctly, you will be asked for the pin. Again, the default is “000000”

Next up, lets load our new key, you can validate that there are no other certs on the card by using “certutil -scinfo”

The command to load the certificate is:

certutil -v -csp "Microsoft Base Smart Card Crypto Provider" -p <pw> -importpfx <pathtopfx>

You can validate the card is successfully loaded using the “certutil -scinfo” command.

Now that the keys loaded, we should change the default pin. To do this, change your working directory in command prompt to:

C:\Program Files (x86)\PIVKey Installer\PIVKey Admin Tools

Next run the commad:

pivkeytool.exe --changepin <new-pin> --userpin 000000

I do want to actually mention that there is a GUI Interface included for managing the smart card, but I wanted to focus on an agnostic way of doing this for the most part, if you’re interested in using the GUI, you can find it in your AppData folder.

One last thing, I know, it continues. Now all we have to do is map that certificate to the appropriate PIV slot on the card:

pivkeytool.exe --mapdefault --userpin <userpin>

Domain Controller Certificates

Now I’m not going to walk through the full steps here, I’m just going to tell you what you need to do to set this up for Smart Card Authentication.

  • On your enterprise CA, make the Domain Controller Authentication Template published to AD.
  • On your Domain Controller(s), enroll in a Domain Controller Certificate issued by the new CA.

Logging in with the Smartcard

Now that we’ve got the card loaded and PIN changed, let’s validate that we can login. I’m going to remote into my file server using my user account that I’ve temporarily added to the remote desktop users on that computer.

As you can see, we ran into some issues there with passing the smart card credential through RDP. This is normal when you don’t have the Mini-driver installed on the computer you’re remoting into. That can be fixed by simply A) installing the minidriver, or B) uninstalling the minidriver on the computer you’re using to remote.

Additional Thoughts

If you you really want to use smart cards to their full capability, you want to ensure that Smart Cards are required for interactive logon. This is a setting in the AD Object of a user that actually randomizes the hash to protect against pass the hash attacks and also ensures that users can’t login without their smart card.





Posted in PKITagged , , , , , ,