YubiKeys demystified

When I saw the Bloodhound Developer use his YubiKey at Black Hat to access Github (in front of hundreds of people), I knew then I had to get a YubiKey of my own!

This article documents some of the initial “hands-on” experience – with accompanying comments and conclusions.

What is a YubiKey anyway?

Simply stated, a YubiKey is a hardware token used for “Two-Factor Authentication” (“2FA”).
However, hiding behind this rather mundane description is a simply marvelous piece of technology.

Basic Technologies[1]

The Wikipedia article sums it up well:
“The YubiKey is a hardware authentication device … that supports
  • one-time passwords, public key encryption and authentication,
  • and the Universal 2nd Factor (U2F) protocol …
It allows users to securely log in to their accounts by:
  • emitting one-time passwords or using a FIDO-based public/private key pair generated by the device.
  • YubiKey also allows for storing static passwords for use at sites that do not support one-time passwords….
Facebook uses YubiKey for employee credentials,… and Google supports it for both employees and users.”
The devices implement:
  • the HMAC-based One-time Password Algorithm (HOTP) and
  • the Time-based One-time Password Algorithm (TOTP), and
  • emulation to identify themselves as a keyboard that delivers the one-time password over the USB HID protocol.
The NEO and NEO-n devices also implement:
  • OpenPGP card protocol using 2048-bit RSA keys. This allows users to sign, encrypt and decrypt messages without exposing the private keys to the outside world.
The NEO device also has
  • NFC support.
The 4th generation YubiKey … includes support for:
  • OpenPGP with 4096-bit RSA keys, and
  • PKCS#11 support for PIV smart cards, a feature that allows for code signing of Docker images.
When the YubiKey is first inserted into the USB, it:
“Identifies as a USB keyboard, smart card, and smart card reader – no client software or drivers need to be installed, no batteries, no moving parts.”

Here’s what the keys look like (courtesy Wikipedia op cit):

And here is a screen shot just after driver initialization showing the different devices:
Note that full vendor documentation is here: https://www.yubico.com/support/documentation/ 

Key storage

The YubiKey offers the following credential storage – all at the same time on the same device:
“ two symmetric key “slots” that you can configure to store credentials, such as one for Yubico OTP (default in slot 1) and one for OATH-HOTP.
You can configure the same YubiKey as:
  • a smart card (PIV-compatible) and program the YubiKey for touch-to sign code signing with Docker.
You can store:
  • up to 32 OATH credentials (TOTP or HOTP) on the YubiKey 4 and access them using the Yubico Authenticator application.
In addition, you can have:
  • an unlimited number of U2F credentials – these include Gmail plus other Google apps, GitHub, Dashlane, and Dropbox, and more.”
The following diagram from the YubiKey 4 data sheet (op cit) shows this:

Different devices

The YubiKey 4 family includes the following devices:
  • YubiKey 4: The basic “workhouse” token supporting up to 4096-bit RSA Keys. Usable for Docker code signing
  • YubiKey Neo: Supports Android NFC but only supports up to 2048-bit RSA keys
  • YubiKey 4 Nano: Identical to the YubiKey 4 but with smaller form factor designed to fit into a USB slot.

The hands-on testing for this article was done with a YubiKey Neo.

No “free” lunches: Security “lock-down”

Yubico certainly took a cautious, conservative stance in the basic design of their technology. (The word “paranoid” comes to mind.)

Two important concepts to note:
  • No firmware upgrades: Yubico has a policy that no token gets firmware upgrades. New firmware is released on the next generation of tokens. However all new firmware is strictly backwards compatible with everything that went before.
  • Write-only: The YubiKey is a write-only device. No credentials or key material can ever be read out from the device.
For more information, see here as well as The YubiKey Manual.

Functional overview

The following sections give a quick overview of important YubiKey function.

Legacy “2-slot” operation

The following material is for comprehension / context only.
In testing, none of the following function was actually used.

The original YubiKeys had only 2 programmable slots. The following description of basic OTP (“One-time Password”) generation is described in The YubiKey Manual / Usage, configuration and introduction of basic concepts:
The YubiKey comprises an integrated touch-button that triggers the OTPgeneration.
Generated OTPs are sent as emulated keystrokes via the keyboard input path, thereby allowing the OTPs to be received by any text input field or command prompt.
… the basic OTP generation scheme can be conceptually described as:
1. The YubiKey is inserted into the USB port. The computer detects it as an external USB HID keyboard
2. The user touches the YubiKey OTP generation button
3. Internally, a byte string is formed by concatenation of various internally stored and calculated fields, including as a non-volatile counter, a timer and a random number.
4. The byte string is encrypted with a 128-bit AES key
5. The encrypted string is converted to a series of characters that are outputted as keystrokes via the keyboard port
This can be demonstrated simply.
  • Insert a YubiKey into a USB slot.
  • Give focus to a text editor such as Notepad.
  • Touch the key.
  • Sequences of random numbers will appear in the text editor.

In practice each of the two “slots” in the YubiKey can be programmed individually in one of the following modes:
  • OATH-HOTP mode
  • Each time the key is pressed, the counter increments and a new passcode is generated.
  • Challenge-Response
  • Either Yubico OTP mode or HMAC-SHA1 mode
  • API access only
  • Can be programmed to send a response only when the key is pressed.
  • Static Password

When both “slots” are programmed, then a “short” press (0.3 – 1.5 sec) generates a OTP from slot 1. A “long” press (2.5 – 5 sec) generates a OTP from slot 2.

YubiCloud Validation Service

Note: None of the functions tested required the following service.

As delivered, the YubiKey “slot 1” is programmed by Yubico for operation with the YubiCloud OTP Validation Service. This is a Cloud-based SAAS for basic OTP validation (to avoid having to deploy one’s own validation servers).

HOTP vs TOTP: Time-generated passcodes are better

The YubiKey is essentially event-driven. A finger touch bumps an OTP counter (eg OATH-HOTP) to cause the next passcode to be generated and output.

This is in contrast to the Google Authenticator-style of passcode generation. In OATH-TOTP, a new passcode is generated (typically) every 30 sec.

The YubiKey has no battery. Its built-in clock only runs when power is supplied through the USB port.

To generate OATH-TOTP passcodes, helper code needs to run on the host computer. In this mode, the YubiKey serves as a credential store only.

However even Yubico recommends TOTP over HOTP! The following is from the Yubico Authenticator User's Guide:
A TOTP password has a shorter lifespan than an HOTP password, which may be valid for an unknown amount of time (or until your next login).
A TOTP password requires less maintenance than an HOTP password but the time between the device and the server needs to be synchronized. HOTP passwords require more maintenance but no synchronization.
TOTP is the more secure one-time password solution.
It is important to understand the maintenance required by OATH-HOTP.
  • If the event counter is out of sync with the server, passcodes are rejected.
  • Typically, the server-side application will provide a special “synchronization” mode with a window-size of 50 or more. If 2-3 user-supplied consecutive passcodes fall within the window, the server adjusts its counter to the new value.

In OATH-TOTP there is no such requirement. Lack of synchronization due to “timer drift” is typically handled transparently by network time synchronization.
Because of the ongoing maintenance required (end-user self-service “hassle” or administrator overhead), OATH-HOTP should be avoided whenever possible.

The YubiKey 4 to the rescue: Significant new function

Yubico had a significant technological challenge on their hands. The world was going to OATH-TOTP because of ease of use, and their native AuthN technology was the user-unfriendly event-driven HOTP.

Yubico’s answer was the YubiKey 4 generation technology.

With the YubiKey 4, Yubico added significant new function to their token technology to reflect current trends.[2]

Basic modes of operation

There are 3 basic modes of operation. The NEO Manager tool is used to configure which modes are currently operational.

The default configuration is “All modes active”. Each of the 3 modes can coexist and function simultaneously with the other modes.

The three modes are:
  • OTP mode: Legacy YubiKey functions available with the two programmable configuration slots
  • CCID mode: smart card elements including OpenPGP, PIV, and YubiOATH applets. YubiOATH applet is used to store OATH-TOTP and OATH-HOTP credentials that can be accessed through Yubico Authenticator.
  • U2F mode: Universal 2nd Factor (U2F) functionality.
In terms of the host computer, the Yubikey emulates 3 different devices:
  • HID Keyboard
  • CCID Smart Card
  • FIDO U2F HID Device.

Supported Authentication protocols

Each mode has its associated AuthN protocols:
  • OTP mode:  Legacy Yubico “slot” protocols including:
  • Yubico OTP (programmed by Yubico in Configuration Slot 1 by default)
  • Challenge-Response
  • Static Password
  • CCID modeUSB CCID compliant Smartcard interface supporting:
  • OATH-TOTP, OATH-HOTP: This mode has storage for up to 32 OAUTH-HOTP and OATH-TOTP credentials.
  • OpenPGP key pairs.
  • JavaCard 3.0 / JCOP 2.4.2 R1 execution environment: OpenPGP
  • Identity card standards
  • PIV[3]: The key can act as a smart card with RSA / ECC certificate from a Windows CA for smart card login to Windows OS.[4]
  • Mifare Classic emulation for proximity cared readers[5]
  • U2F mode:
  • FIDO Universal 2nd Factor U2F support
  • Unlimited number of credentials.

Neo key

The “Neo” key is similar to the Yubikey 4 and Nano 4. However there are slight differences.

The Neo key has additional function for  NFC communication with Android mobile devices:
  • Near Field Communication (NFC) interface allowing contact-less data exchange in NFC- and RFID environments
  • ISO14443A RFID/NFC interface
  • NDEF applet installed for interaction with YubiKey functionality.[6]
However Neo's additional function comes at a price:
  • A maximum of approximately 28 OATH-HOTP / OATH-TOTP can be stored on the key. The regular keys can store 32 OATH credentials.

  • The Neo only supports public certificates as follows: maximum size RSA 2048, ECC p256. The regular keys support RSA 4096 / ECC p384.

CCID mode: smart card support

The Nov 2014 lvm.net article Smartcard features on the YubiKey NEO gives a good overview of the smart card function on the YubiKey 4 / 4 Nano / Neo:

The [new YubiKey] includes a Common Criteria–certified JavaCard secure element, which can be loaded with several JavaCard applets. ... In order, these applets are the basic NEO OTP functionality, the NFC data-exchange functionality, an OpenPGP applet, a Personal Identity Verification (PIV) applet, and the HOTP/TOTP OATH applet.

According to the Yubico documentation YubiKey PIV Support, the Neo has 4 PIV certificate slots whereas the YubiKey 4 / 4n has 24. As specified in the PIV standard, the slots have different functions: (login) PIV AuthN, Digital Signature, (Encryption) Key Management, and (Physical access) Card AuthN. 

The U2F Authentication protocol

Before diving into the test results, a quick look at the U2F Authentication protocol would be useful.


From Wikipedia:[7]
Universal 2nd Factor (U2F) is an open authentication standard … [for] two-factor authentication using specialized USB or NFC devices based on similar security technology found in smart cards. While initially developed by Google and Yubico, with contribution from NXP, the standard is now hosted by the FIDO Alliance.
The standard was developed in late 2014 but there apparently is considerable resistance to widespread adoption:

  • Firefox / IE: Microsoft / Mozilla browsers still do not natively support U2F.

  • Major web sites with proprietary 2FA: Most major web sites provide their own (often “clunky”) approaches to multi-factor AuthN (e.g. 2FA codes sent by SMS). Apparently these sites do not want to invest in U2F.  This includes “almost everyone”: e.g. Facebook, PayPal, Amazon, and LinkedIn.
Possibly the lack of support is due to partner mistrust of the “800-pound gorilla” Google’s standard. Or perhaps there is a perception that U2F is somehow limited to hardware tokens only.


Basic protocol flow

The U2F protocol is elegant in its simplicity. U2F is a simple challenge-response protocol:
  • The U2F device registers by sending its U2F public key (kpub) to the Relying Party (“RP” – typically a web site).
  • To authenticate accesses, the RP sends a challenge to the U2F device.
  • The U2F signs the challenge with its private key (kpriv).
  • The web server RP looks up the corresponding public key (kpub) to verify the response.
The following diagram shows this basic interaction:

Mitigating well-known attack vectors

Various extensions to the basic protocol are defined to mitigate various attack vectors. The result is a lightweight, robust 2FA protocol:

Attack vector
Client adds Origin URI and sends this along in the response packet. The RP verifies that the information is correct.
Client adds the TLS Channel ID (if supported) to the response.
Prevent RP from tracking devices between user accounts
U2F device generates a new application-specific key pair / key handle for each new registration.
The RP stores the handle and sends it with the challenge.
The device then knows whether to authenticate with User1’s key or User2’s key (if device is shared by User1 and User2)
Device cloning
The YubiKey is tamper-resistant.
To protect software-based implementations, the U2F device increments a counter and adds this to the response. The RP checks that the

Security robustness

Just how solid is the protocol?

Two researchers presented a recent paper (SSTIC 2016) that analyzed the robustness of the U2F protocol to various attacks:
This paper draws a picture of the security brought by U2F and ultimately compares the protocol with some 2FA schemes: Short Message System (SMS) codes, Time-based One-Time Password (TOTP) and TLS client authentication using certificates.
… our study tends to confirm that the security features offered by the U2F protocol are superior to the security brought by many SMS-based and TOTP-based second-factor solutions. This feat comes from the use of hardware secure elements, a phishing-resistant approach, the use of strong public key cryptography and an authentication scheme with distinct public keys per website
... At a theoretical level, the web part of the U2F protocol seems sound.
… Overall, the U2F protocol seems like a viable second-factor authentication scheme with phishing-resistant properties. Its ease of use and privacy features further promotes it for a wide web deployment. Even so, at the time of writing, our comparison of U2F with the TLS authentication scheme relying on client certificates indicates that the latter should be used in environment with the most stringent security requirements.
In a nutshell, U2F appears to be reasonably solid, is easy to use, and is better than SMS or OATH-TOTP.

Client-side certificates are likely more robust (at the cost of significant operational overhead).

The Software

Unfortunately Yubico’s software is not as stellar as their hardware. This section summarizes the tools they provide.

The Yubico Authenticator


The Yubico Authenticator is essentially a drop-in replacement for Google Authenticator – with the following differences:
  • The Yubico Authenticator runs anywhere:
  • pre-compiled binaries for Windows, OS X, and Android
  • custom PPA for Ubuntu
  • The python code can also be installed using pip.
  • The credentials are stored – you guessed it – on the YubiKey.
  • Sadly, the GUI interface is not very user-friendly.
From the Yubico Developers’ Documentation:[9]
The Yubico Authenticator is a graphical desktop tool and command line tool for generating Open AuTHentication (OATH) event-based HOTP and time-based TOTP one-time password codes, with the help of a YubiKey that protects the shared secrets.
Essentially, the Yubico Authenticator is the functional “glue” that exposes much of the YubiKey function to the end user:
Usage of this software requires a compatible YubiKey device. Yubico Authenticator is capable of provisioning and using both slot-based credentials (compatible with any YubiKey that supports OTP) as well as the more powerful standalone OATH functionality of the YubiKey NEO.

Adding new credentials

To the end user, the Yubico Authenticator appears as a somewhat awkward “drop-in” replacement for Google Authenticator.

To enter a new TOTP credential, “File → Add” presents the user with the following screen:

If one is lucky, clicking “Scan a QR code” will actually work and the TOTP secret will be automatically captured and stored on the YubiKey.

In not, then the raw OATH-TOTP Base32 has to be calculated and entered manually. This will be discussed in greater detail in a following section.

Entering an HOTP credential is quite similar. The counter is set to 0 when the credential is created.

Using a credential stored on the YubiKey

When the Authenticator is started, no credentials are available:

When the YubiKey is inserted in the USB slot, the Authenticator accesses the names of the credentials stored in the token:

As already mentioned, Yubico’s secure design philosophy dictates that:
  • No credentials can be read from the key.
  • Once a credential is stored on the key, it cannot be changed.
To obtain a passcode, the user clicks on the corresponding icon (the small “clipboard” to the right of each credential). Clicking once obtains a passcode. Double-clicking obtains a passcode and minimizes the application.

Awkward user interface

This GUI application proved to be somewhat awkward to use.

If an icon is double-clicked by error (instead of a single click), the application mysteriously disappears.

Since the token is “write-only”, credentials have to be deleted and re-provisioned to be updated. This in itself is difficult at first.

The “delete” function is hidden away. The user has to right-click the credential to be deleted and a “delete” pop-up suddenly appears.

Worst of all however is the procedure for manual entry of secrets. Unfortunately, on a Windows PC at least the “QR scan” function works only intermittently. This means that the user has to manually enter secrets. This is not an easy task.

Manual entry of secrets

The Authenticator requires that secrets be entered in Base32 format only.[10]
Normally secrets are presented in Google Authenticator format:

To convert to OATH-XXXX compatible base32 format, first the spaces must be removed. Next everything is converted to uppercase. Finally the base32 encoding is done.

The following shows this in Python:

>>> import base64
>>> s = "j2k c2d r3d 72k xxy w"
>>> mystr = s.replace(" ","").upper()
>>> mystr
>>> base64.b32encode(mystr)
The highlighted string after the encoding is what Authenticator expects to receive.

If the secret is presented in hex format, then the following Python code can be used:

import base64
my_bytes = bytearray.fromhex("8ec3521adf9393f09c6842ae0094e21")
Result is:

NFC support

The Yubico Authenticator supports Android NFC communication when used with the new YubiKey Neo.

The manual[11] gives the following cautions:
Position your YubiKey NEO as close to the NFC antenna (of your device) as you can and hold it there for two to three seconds. Due to the small size of the YubiKey NEO and its own antenna, the YubiKey NEO needs to be very close to the NFC antenna of the device. If you are unsure where the NFC antenna is located on your mobile device, review the specifications on the manufacturer’s website.
The technology actually works reasonably well if the phone is adequately charged.

The first few tries were awkward. Yubico Authenticator beeped and moaned strangely as I hunted for the phone’s NFC “sweet spot”. With some practice, it was possible to activate Authenticator using NFC through the phone’s protective cover.

The manual also says that Android Beam should be turned off. This is probably a wise thing to do in any case.

Maintenance Tools

Yubico provides several small programs to configure the YubiKeys.

During functional testing, the default configuration of the YubiKey 4 / Nano / Neo seemed to work just fine. These tools apparently would be necessary for custom configurations / commercial bulk deployments and other specialized use cases.

Neo Manager

The Neo Manager tool actually is for the entire generation of YubiKeys: YubiKey NEO, YubiKey NEO-n, YubiKey 4, and YubiKey 4 Nano.

All this program does is switch operating modes on the various keys.

The three operating modes are:[12]
  • OTP (the two configuration slots)
  • U2F
  • CCID (smart card functionality used with Yubico Authenticator, PIV, OpenPGP)
The default configuration has all 3 modes enabled.

With the tool, any combination of the modes to be configured by clicking checkboxes:

Not much but that’s all.

YubiKey Personalization Tool

This tool exposes all internal functional parameters of the YubiKey for provisioning custom configurations.

Yubico proudly calls the tool “The Swiss Army Knife for the YubiKey”.

For normal use cases, the default YubiKey configuration should work without requiring tweaking. A lot of the complexity of the tool addresses legacy function with little current relevance.

If you do feel a need to use the tool, be sure to read the 48 page manual first.[13]

The screenshots that follow give a quick idea of the complex tool functions. First is the tool’s home page:

The "busy" page for configuring a slot in OATH-HOTP mode gives a view of the underlying complexity:

PIV-related Tools

There are also tools related to smart card function. Due to lack of time, none of this function was tested. The Windows tools with graphical user interface appear to be oriented towards Windows smart card support including bulk deployment.

At time of writing, probably what probably is the most important manual had a broken link (!). The manual can be found here: YubiKey PIV Deployment Guide

There is also a command line tool for basic parameter configuration including management and card PINs. 

Functional Testing Results

The previous sections gave a brief overview of the Yubico technology. The accompanying software tools were briefly described.

This section continues with a quick discussion of results obtained during "hands-on" exploration of some of the main YubiKey function.

Great integration but sometimes complex and confusing

Given the flexibility of Yubico’s technology, it is not surprising to discover that the YubiKey integrates well with a significant number of different technologies. A wide variety of use cases are supported.

The downside is that the integrations are somewhat complex and confusing, at least initially. This is due to the following reasons:

  • Security First and Foremost: Yubico has a “no compromise” attitude to security. Their token is designed for use in high-security applications. The tradeoff is increased complexity and lack of conviviality for end-users.
  • No Technology “sunset”: Yubico never “sunsets” their technologies. People do not have to buy new keys to keep vendor support. Anything that ever worked, will still work. Over the years, the layers of technology function have accumulated to form a somewhat complex set of interacting function.
  • Historical legacy: Yubico has been a key player in the token market for a number of years. Integrations over the years vary in approach as new generations of tokens incorporate additional function. The result is that everyone seems to have their own special way of integrating YubiKeys
The following sections look quickly at various integrations with leading vendors.


Dominik Reichl, the author of KeePass, provides a plugin for OATH-HOTP:

The OATH-HOTP secret key is stored in the second slot of the YubiKey.

Simplistic Recovery Mode

Because the passcode generation is event-driven synchronization problems can result. A simplistic “Recovery Mode” dialogue is provided. The original HOTP secret key is entered to gain access.

Once access is recovered, then the existing OATH-HOTP credential is no longer usable and must be deleted. The entire OATH-HOTP provisioning process has to be repeated to generate a new credential.

No “secure desktop”

Normally the Yubico Authenticator will be used to obtain the passcodes from the YubiKey. This means that the KeePass option “Tools/Options/Security/Enter master key on secure desktop” must not be checked.

Otherwise the desktop will not be accessible (including the Yubico Authenticator program).

Entering the secret key

The Yubico Authenticator requires that the secret key be entered in Base32 format. This is certainly not the most intuitively obvious format for end-user interaction.

Fragile Synchronization / Potentially exposed secret

The HOTP keeps its status information in a cleartext XML file stored on the PC. The HOTP counter as well as the secret key are (probably) stored in this file.

If the same KeePass file is shared between two computers, then the HOTP plugin file has to be shared (and carefully synchronized!). If there is any de-synchronization, then HOTP AuthN breaks and recovery mode is the only option.

Managed code assemblies are usually relatively easy to reverse engineer. This means that the secret key is likely to be relatively exposed. The extra security provided by the YubiKey is nullified by the exposed secret key.


The KeePass integration uses legacy YubiKey OATH-HOTP Authentication. The result is a fragile, relatively insecure implementation that is more useful as a “Proof of Concept” than for actual production.

U2F-enabled sites: GitHub, Dropbox

Works well, easy to use

GitHub[15] and Dropbox[16] both are U2F-enabled. Initial registration as well as subsequent Authentication are easy to do and work well.

But … (Things to remember)

On any site where 2FA is configured, it is important to have a backup means of AuthN if the primary method no longer functions.

This is especially true for U2F AuthN. Unless the RP website allows 2 different tokens to be registered simultaneously for the same user, an alternative method of AuthN will be required.

Remember also that currently only the Chrome browser supports U2F.

Git / GitHub Signing commits / tags

Both Git and GitHub support use of OpenPGP certificates for signing commits as well as tags.

The OpenPGP certificate can be securely stored in the YubiKey.

For more information, see Git Docum: Chap 7 Git Tools - Signing Your Work, as well as GitHub Help: GPG support.

Due to lack of time, the Git signing function was not tested.

OpenPGP certificates for Ssh login with YubiKey

As previously mentioned, the smart card support (OpenPGP, PIV - Windows, Docker) was not tested due to lack of time. (In fact this function could be the subject of an another entire blog post.)

Using an OpenPGP certificate for Ssh login

OpenPGP certificates can be used for Ssh login (instead of the default RSA or DSA Ssh keys). The seminal post on use of YubiKeys for Ssh signon is Eric Severance Blog Jan 2015: PGP and SSH keys on a Yubikey NEO. (Note that the comments for this article mention some minor improvements / errors).

An OpenPGP authentication subkey can be used with OpenSSH to login to an ssh agent. The GngPG gpg-agent has a flag that allows it to function as an ssh-agent. (In fact both OpenSsh RSA keys as well as OpenPGP certificates can be converted to OpenSSL PEM certificates. See here and here also.

OpenPGP certificates on YubiKeys

The suggested robust approach involves using the YubiKey to create OpenPGP subkeys for encryption / signing / authentication. The keys are generated on the YubiKey itself so that the secret keys never leave the secure YubiKey environment.

The last link mentions that the Yubico OpenPGP applet supports a "Touch" function: "When ... enabled, the result of a cryptographic operation involving a private key (signature, decryption or authentication) is released only if the correct user PIN is provided and the YubiKey touch sensor is triggered."

Possible "Gotcha"

Note that there is a possible "Gotcha" in the provided support. A comment to one of the articles above mentioned the  following:

If you happen to use YubiKey NEO with OpenPGP using gpg-agent/scdaemon, you may get the following error message:

no slots
cannot read public key from pkcs11
The reason is that scdaemon exclusively locks the smartcard, so no other application can access it. You need to kill scdaemon, which can be done as follows:

gpg-connect-agent SCD KILLSCD SCD BYE /bye

Google / Gmail

Since Google was instrumental in the initial design and development of U2F, it comes as no surprise to discover that Google’s applications are U2F-enabled.

However, to use U2F the new Google “Push” 2FA had to be disabled. This (sort of) makes sense. U2F AuthN based on a YubiKey token is more robust than a simple 1-click “Push” AuthN on a possibly insecure mobile Android phone.

Nonetheless, this means that a working Google Authenticator should be kept as a backup 2FA method. (Note that Google also provides 1-time use Recovery Codes as an alternative method.)


Duo took 2 different approaches to YubiKey integration:

  • OATH-HOTP: Is supported but Administrator interaction is required (with accompanying administrative overhead)

  • U2F: Is supported only in the high-end paid editions of Duo (i.e. Enterprise and Platform editions)
Note that both versions of Yubico OATH-HOTP are supported by Duo:
  • The legacy OATH-HOTP (using YubiKey slot 2)
  • The newer OATH-HOTP as supported by the Yubico Authenticator.

OATH-HOTP tokens

OATH-HOTP tokens have to be added by the Administrator.
  • Bulk provisioning: Tokens can be added in bulk (by uploading a CSV file with token information[17]) or manually directly in the Dashboard.[18]

  • Resynchronization: If non-zero, the HOTP counter has to be entered along with the token serial number (in decimal) and the token secret key.
Resynchronization of HOTP tokens also requires Administrator intervention.[19] There is no self-service portal function available for the user to resynchronize a token.

All-in-all there seems to be little justification for using OATH-HOTP (with its accompanying administrative overhead) when U2F is available (- except for cost considerations of course).


Since U2F AuthN is not supported except in the most expensive versions of Duo, Duo’s U2F was not tested.

AWS – Amazon Web Services

Amazon supports generic OATH-TOTP 2FA.[20]

The Yubico Authenticator supports OATH-TOTP as a (more secure) drop-in replacement for Google Authenticator.

Windows / Linux login

Yubico provides a PAM module as well as a Windows credential provider.[21] However these were not tested as Duo provides equivalent (and rock-solid reliable) function with centralized Administration through their SAAS application.

Windows smart card login was not tested either due to time limitations.


Notary, an open source program, is used to generate a 4096-bit PIV certificate. This is used to sign the Docker image content.

Note that only the YubiKey 4 / 4n support RSA 4096 keys which are required for Docker. The Neo does not support Docker signing.

Summing it all up

In a nutshell:
  • Great Technology: Overall, the YubiKey is a exciting technology. The YubiKey 4 or Nano is probably more useful unless you really need to use credentials on an Android mobile phone.

  • U2F? What's that?: U2F appears to be going nowhere fast. Hopefully the world will get over their politics and start to use this powerful, lightweight 2FA technology.
  • YubiKeys are quite functional for the few U2F-enabled web sites that do exist: Google, Dropbox, GitHub. Duo’s lack of YubiKey U2F support in the free version is disappointing.

  • "Clunky" Software tools: The Yubico Authenticator is painful to use but necessary.

  • TOTP codes (eg AWS) can be moved from Google Authenticator to the more secure YubiKey equivalent. But brush up on your Python for base32 conversions.

  • Certificates as well: Certificates can be stored on the YubiKey as well (e.g. code signing, smart key login) but due to lack of time this function was not tested. GitHub and Docker support code signing with YubiKeys. Probably a good idea would be to enable Yubico "Touch" support for certificate use. Also a PIN should be put on the card to protect against unauthorized modification / use. 

  • Duo for login 2FA: Use Duo for Windows / Linux 2FA support.

[1] The full set of Yubikey documentation can be found here: https://www.yubico.com/support/documentation/ 
[2] For more information, see the product specification sheets as well as the YubiKey NEO Manager Quick Start Guide
[6] See http://forum.yubico.com/viewtopic.php?f=26&t=1963 for more about the Yubico NDEF programming.
[11] Yubico Authenticator User's Guide
[12] Cf NEO-Manager-Quick-Start-Guide, Introduction, pg 4
[13] Cf YubiKey Personalization Tool User Guide March2016
[15] For more information concerning GitHub integration see: https://www.yubico.com/support/documentation/how-to-use-your-yubikey-with-github/ 
[18] For the details, see https://duo.com/docs/yubikey 


Anonymous said...

Great post! Very informative!

Blogger said...

Bluehost is definitely one of the best hosting provider for any hosting services you require.