Tag Archives: Smart Cards

BitLocker, Windows 7, and Smart Cards

Mounting frustration with PGP Whole Disk Encryption has me revisiting BitLocker options this week. We last touched on this subject back in the early days of Vista. It appears that enough has changed with Windows 7 that we need to do some policy updates.

First off, I discovered that the BitLocker system volume encryption wizard was not presenting me with startup PIN or startup key options. Further, it also was not backing up recovery key data to Active Directory, as we originally designed it to under Vista. Why? Because Vista BitLocker policies do not apply to Windows 7! A quick step through the “Windows 7”-specific settings in Computer->Policies->Administrative Templates->Windows Components->BitLocker Drive Encryption (and the child “Operating System Drives” settings), and we are back in action.

Next, I noticed new settings related to smart cards in the new Group Policy settings. Does BitLocker now support storage of drive encryption keys on a Smart Card? No… not for system volumes anyway. Still, I was intrigued by option for removable and non-system volumes, and decided to try encrypting my office eSATA drive using BitLocker and a Smart Card certificate.

Microsoft provides the following information on certificate template requirements for BitLocker:
Madeningly, they specify that you should provide the ‘Enhanced Key Usage OID value of’, if you are going to specify an OID. They also say that your “key usage attribute” should be one of three possible options with names like “CERT_DATA_ENCIPHERMENT_KEY_USAGE
“. The problem with this guidance is that the Certificate Template Manager MMC snapin does not expose any such options, and I cannot find docmentation for management of certificate templates using “certutil.exe”, or any other available command line utilities. Am I supposed to use ADSI edit to do all my certificate management these days? Sheesh.

Some googling determined the following:

  1. Enhanced Key Usage, or EKU, is labeled “Application Policies” in the Certificate Template MMC, and they are exposed under the “Extensions” tab of a template properties dialog box.
  2. OID info is not displayed in the list of Application Policies. However, OID maps to the friendly name “BitLocker Drive Encryption”. Select this policy and add it as a cirtical extension, or just leave the Application Policies list empty. Note that you will need to have the “BitLocker Drive Encryption” feature activated on any system from which you you are editing the Certificate Template (I am indebted to DXter for this post which led me on the path to solving this little mystery).
  3. The “key usage attribute” referred to in the BitLocker documentation also is exposed in the “Extensions” tab of the Certificate Template properties dialog. In this case, we will be looking at the “Key Usage” extension. Selecting a value of “Allow key exchange only with key encryption (key encipherment)” appears to work.
  4. Under the “Request Handling” tab, I also specified that the certificate will be used for “Encryption”, and not “smartcard logon”, since I don’t want to use this same cert for Smart card logon… perhaps that will change later on. We also needed to enforce the use of the “Microsoft Smart Card Key Storage Provider” under the “Cryptography” tab, since we want to generate the certificate key on the smart card. (Note that you need CNG-compliant cards to use this option. CNG cards are the way to go!)

Exploring Smart Cards and Windows Logon

I have been having some “fun” this week in exploring two-factor authentication possibilities for Macintosh and Windows 7 clients when connecting to Server 2008 and Server 2003 resources, especially via RDP.  Findings so far:

All Smart Cards are not created Equal:

  • Microsoft released a new Cryptographic API (CNG) with Vista/Server 2008.  This API allows Smart Cards to use the “Microsoft Smart Card Key Storage Provider” CSP (which, apparently, is part of the MS “Base CSP”), instead of a vendor-specific CSP, when generating certificates for Smart Card-based logon.  You must still install a driver for each Smart Card, but very often these drivers are available though Windows Update.
    • Aladdin/SafeNet eTokens do not support CNG, so you cannot use CNG-based Certificate Templates (i.e. Server 2008-compatible templates) when issuing Smart Card Logon certificates to Aladdin eTokens.  Thus, you must make sure that any Certificate Template that you use for Smart Cards are compatible with Server 2003 or earlier.  You also will need a software stack including the eToken CSP and drivers before you will be able to perform Smart Card login using an eToken.
    • Gemalto .NET Smart Cards do support CNG, so you can use CNG certificate templates with these Smart Cards.
    • RSA SecurID Hybrid Authenticators do not appear to support CNG, according to their (dated) product data sheet, so I expect you would need a custom CSP to use these for Windows Logon, too.
  • PGP Desktop can be configured to use keys stored on a Smart Card to unlock PGP-WDE encrypted drives.  However, only a few vendor’s Smart Cards are supported in this capacity, probably because PGP has hard-coded in support for only a few CSPs:
    • Aladdin eToken devices are supported both for WDE sign-on and for Administrator Key storage.
    • RSA Smart Cards are supported for WDS sign-on only
    • Gemalto Smart Cards are not supported at all.

Web Service Enrollment was dead:

  • Most how-to sites you visit on certificate enrollment and smart card logon (including one in Tech Net) state that you should set up a Certificate Enrollment Agent Workstation to use the Web Services interface on your MS Certificate Server.  Guess what?  The procedures do not work anymore on Server 2008:
  • Server 2008 R2 has a new Web Enrollment interface that supports Smart Card enrollment from Vista/Win7 workstations.  Ban the use of Server 2008 R1!
  • Use the “Certificates” MMC snap-in in place of web enrollment if you must run Server 2008 (R1).

RDGateway – Smart Card Authentication requires trust:

  • Smart Card auth to our Remote Desktop Gateway Load Balancing cluster (based on F5) was failing.  Apparenly something about the SSL-offload configuration was creating a trustworthiness problem, and this was preventing Kerberos/Smart Card authentication from working.  We switched to a TCP/Layer-4 forwarding config, and now Smart Card authorization works just fine.  Note that the config that works is not the one that was recommended by F5.  They are big into TCP offload over there.  The thing is, for Kerberos and Smart Cards to work in an SSL-offload config, you need F5’s expensive Advanced Client Authenticaiton module.  I do not need more cost and complexity, so we will keep things simple this time.