How to Add Dual-Factor Authentication to an OpenVPN Configuration Using Client-Side Smart Cards

Dual-factor authentication is a method of authentication that combines two elements: something you have and something you know.

Something you have should be a device that cannot be duplicated; such a device can be a cryptographic token that contains a private secret key. This private key is generated inside the device and never leaves it. If a user possessing this token attempts to access protected services on a remote network, the authorization process that grants or denies network access can establish, with a high degree of certainty, that the user seeking access is in physical possession of a known, certified token.

Something you know can be a password presented to the cryptographic device. You can't access the private secret key without presenting the proper password. Another feature of cryptographic devices is that they are prohibited from using the private secret key if the wrong password has been presented more than an allowed number of times. This behavior ensures that if a user loses his device, it would be infeasible for another person to use it.

Cryptographic devices are commonly called "smart cards" or "tokens" and are used in conjunction with a PKI (Public Key Infrastructure). The VPN server can examine an X.509 certificate and verify the user holds the corresponding private secret key. Since the device cannot be duplicated and requires a valid password, the server can authenticate the user with high confidence.

Dual-factor authentication is much stronger than password-based authentication because, in the worst-case scenario, only one person at a time can use the cryptographic token. Passwords can be guessed and exposed to other users. In the worst-case scenario, an infinite number of people could attempt to gain unauthorized access when resources are protected using password-only authentication.

If you store the secret private key in a file, the key is usually encrypted by a password. The problem with this approach is that the encrypted key is exposed to decryption attacks or spyware/malware running on the client machine. Unlike when using a cryptographic device, the file cannot erase itself automatically after several failed decryption attempts.

To summarize, PKCS#11 is a standard that can be used by application software to access cryptographic tokens such as smart cards and other devices. Most device vendors provide a library that implements the PKCS#11 provider interface -- this library can be used by applications to access these devices. PKCS#11 is a cross-platform, vendor-independent free standard.

The first thing you need to do is to find the provider library, it should be installed with the device drivers. Each vendor has its own library. For example, the OpenSC PKCS#11 provider is located at /usr/lib/pkcs11/opensc-pkcs11.so on Unix or at opensc-pkcs11.dll on Windows.

You should follow an enrollment procedure:

A configured token is a token that has a private key object and a certificate object, where both share the same ID and label attributes.

A simple enrollment utility is Easy-RSA 2.0, part of the OpenVPN 2.1 series. Follow the instructions in the README file, and then use the pkitool to enroll.

Initialize a token using the following command:

$ ./pkitool --pkcs11-slots /usr/lib/pkcs11/
$ ./pkitool --pkcs11-init /usr/lib/pkcs11/  

Enroll a certificate using the following command:

$ ./pkitool --pkcs11 /usr/lib/pkcs11/   client1

You should have OpenVPN 2.1 or above to use the PKCS#11 features.

$ openvpn --show-pkcs11-ids /usr/lib/pkcs11/

The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.

Certificate
       DN:             /CN=User1
       Serial:         490B82C4000000000075
       Serialized id:  aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600

pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

pkcs11-providers /usr/lib/pkcs11/
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'

pkcs11-providers /usr/lib/pkcs11/provider1.so /usr/lib/pkcs11/provider2.so
pkcs11-id 'aaaa/bbb/41545F5349474E415455524581D2A1A1B23C4AA4CB17FAF7A4600'
pkcs11-pin-cache 300
daemon
auth-retry nointeract
management-hold
management-signal
management 127.0.0.1 8888
management-query-passwords

PKCS#11 is a free, cross-platform, vendor-independent standard. CryptoAPI is a Microsoft-specific API. Most smart card vendors provide support for both interfaces. In the Windows environment, the user should select which interface to use.

The current implementation of OpenVPN that uses the MS CryptoAPI (cryptoapicert option) works well as long as you don't run OpenVPN as a service. If you wish to run OpenVPN in an administrative environment using a service, the implementation will not work with most smart cards because of the following reasons:

Using the PKCS#11 interface, you can use smart cards with OpenVPN in any implementation because PKCS#11 doesn't access Microsoft stores and doesn't necessarily require direct interaction with the end user.