It is manufactured by Yubico.
The current top models are YubiKey 4 (yk4) and YubiKey NEO. The main difference: yk4 has no NFC support, NEO does.

One of its strengths is that it emulates a USB keyboard to send the OTP as text, and thus requires only USB HID drivers found on practically all desktop computers.

Understanding the YubiKey

The YubiKey is a small USB dongle with one button and an LED to communicate with you.

One of its strengths is that it can emulate a USB keyboard to send a password (OTP or static password) as text, and thus requires only USB HID drivers found on practically all computers (desktop, mobile, tablet).

This also makes it vulnerable to keyloggers if the static password functionality is used, which is why if possible one should avoid it and try to only use the OneTimePassword OTP, Challenge-Response and CCID Smartcard functionality.

Possible Inputs

It takes INPUTS in the form of:

API calls sent to the key via the USB interface.

short button press

long button press

Possible Outputs

It transforms these INPUTS into OUTPUTS in the form of:

Sending keystroke keycodes (emulating a USB keyboard and typing for you) This is used to:

type the static password

type the OTP

Sending back a Response via the API (over the USB interface). This is used to send back:

the response of a Challenge-Response request (calculated using either Yubico OTP mode or HMAC-SHA1 mode)

the response of a U2F Challenge-Response request

the response of a CCID Smartcard related request

The Button

The button works by slightly touching. Sometimes it even reacts when you are very close, but are not touching it yet.

Effects of pressing the button

A touch on the button always has one of these functions (depending on the context):

triggering a function (like triggering the output of a static password or of a OneTimePassword (OTP)

confirming / allowing a function or access

inserting / ejecting the smartcard

Two different ways to press the button

If the OTP mode is activated, the button can differentiate 2 different types of touch:

short

long

in order to differentiate between accessing slot 1 (short press) and 2 (long press).

The (USB Connection/Transport) Modes of the YubiKey

Think of these modes as different subsystems on the key that handle different parts of the keys functionality.

What modes are there ?

Yubikeys support up to 3 different USB connection/transport modes (depending on model):

U2F mode (u2f, short u) - this subsystem only supports the U2F protocol. It comes fully configured when you buy a YubiKey. It does neither need, nor support any configuration. It can only be enabled / disabled by setting the mode.

OTP mode (otp, short o) - this subsystem is responsible for OTP, Challenge-Response, Static Passwords. If the transport mode OTP is enabled, the two YubiKey Slots, long press and short press, can be configured and used. These slots can have one of the following credentials configured: a Yubico OTP (which is what comes preconfigured in the short press slot on a new key), a static password, a challenge-response credential, an OATH-HOTP credential. All this functionality is found in the ykman slot commands.

CCID mode (ccid, short c) - this is the subsystem allowing the key to act as a Smartcard (using CCID protocol). (TODO:explain further)

What does a mode do ?

how the YubiKey is accessed (e.g. if the CCID mode is activated, then ykman will access the YubiKey in CCID mode, meaning if you do not have pcscd running, then even a ykman info will fail) and

what functionality is available or not (e.g. if you deactivate the U2F mode, then your YubiKey will not handle any U2F requests anymore)

These modes can be activated/deactivated independently from each other.

Which mode is used?

Only one connection mode will be used at any given point in time to communicate with the YubiKey.

When you plug in your YubiKey one, connection mode will be chosen.
The order of preference (TODO:verify) is:

If the CCID mode is activated, this mode will be chosen.

Otherwise (so CCID deactivated and) if the U2F mode is activated, this mode will be chosen.

Otherwise (so CCID and U2F deactivated and) if the OTP mode is activated, this mode will be chosen.

Get enabled modes

ykman mode will tell you what modes are currently activated/enabled/available.
This could output something like

Current connection mode is: OTP+U2F+CCID

Meaning that currently the OTP, U2F and CCID subsystem of the key are enabled .

Set the enabled modes

ykman mode <MODE> will allow you to define which modes should be activated/enabled/available.

<MODE> can be a string, such as "OTP+U2F+CCID", or a shortened form "o+u+c".With "+" you can combine multiple modes that you wish to be enabled.

<MODE> can be a mode-number, which is one number that encodes several enabled modes (like flags) into one value.The only valid modes when using numbers is 0 - 6 (see here). The extra flags are not part of the mode in that sense, they just need to be set at the same time as the mode is set.

Usually what you want is to make all functionality available (you will still need to potentially configure stuff, see functionality sections below for more details).
In order to do so you can use:

ykman mode c+u+o or ykman mode 6

Note: Using the "80" mode-number or the corresponding "--touch-eject" parameter of ykman mode can only be used when the device is in CCID mode _only_ (by running ykman mode ccid --touch-eject for instance).

Once the --touch-eject flag is set, you should be able to eject/insert the smartcard by pressing the button. The LED should indicate if the card is inserted or not as well.

Warning: But using the 80 mode-number or the corresponding --touch-eject is not recommend as it would prevent you from using the U2F and OTP features of the YubiKey.

Note: The often seen:

ykman mode c+u+o --touch-eject or ykman mode 86

will ignore the --touch-eject and be identical to the above recommended ykman mode 6.

86 is not a valid mode. It might be a bug that the tool accepts higher values (see here).

Two Slots

Only if the OTP mode is activated (see Modes of the YubiKey below), the Yubikey provides 2 slots.

If the transport mode OTP is enabled, the two YubiKey Slots, long press and short press, can be configured and used.

Configuration of the slots

These slots can have one of the following credentials configured: a Yubico OTP (which is what comes preconfigured in the short press slot on a new key), a static password, a challenge-response credential, an OATH-HOTP credential. All this functionality is found in the ykman slot commands.

Note: A slot has either a Yubico OTP or a challenge-response credential configured. More general: One, and only one, type of the above listed possible credential per slot.

There are several flags that can be set during the configuration of the slots.
These flags /cannot/ be read from the device once written. However, the behaviour of the device should change when the flags are set ;)

Note: Actually most of (all of??) the parameters and details you use during configuration of the slots, cannot be read back, once written to the YubiKey.

The LED

The YubiKey has a small green LED able to communicate with you.
Its message to you actually depends on the currently used USB connection mode of your YubiKey.

Note: If the CCID mode is turned on, then the LED of the key is always shortly flashing every two-three seconds once inserted.You can turn the blinking off by disabling the CCID mode. This slow blinking just shows that the device has power, alternatively it shows a need for a button press. On Windows this behavior will typically stop once drivers are installed and it is ready for use. Mac and Linux systems will keep blinking; here the best current workaround to get the LED to blink less is to disable CCID.

The Initial configuration

On a new YubiKey the Yubico OTP is preconfigured on slot 1.

Warning: Before you overwrite your slot 1, please be aware that one is not able to reconfigure the same trust level see here.

Meaning:
Being a security-minded person one could think that it is a good idea to reset configuration slot 1 to a new OTP. But then a "VV" prefix in your credentials must be used. Whereas the factory credentials on your Yubikey use a "CC" prefix!

You can upload a "VV" credential using the Yubico personalization tool GUI or manually upload the new AES key to the [upload.yubico.com website] in order to regain the same functionality than with the original factory configuration.

VV credentials are not less secure than CC. However some services may choose to trust only CC credentials as they believe that the user process is more prone to security vulnerabilities.

This is because you could have malware on your machine or someone intercepting your key when sending it to the YubiCloud. Despite this scenario being extremely unlikely to happen, it needs consideration from service providers.

Limitations of the passwords typed by YubiKey via USB-keyboard -- or "Why do my password look so weak ?"

The YubiKey can type passwords (OTP or Static Password) for you by acting as USB keyboard and sending scan-codes like if you would type.

A limitation of the YubiKey, however, prevents you from choosing characters that require a modifier key other than Shift.
And in order for the YubiKey to work with all possible keyboard layouts (e.g. the Z on a German keyboard has a different scan-code than the Z on a US keyboard) it is necessary to limit the characters used by YubiKey passwords to the ModHex alphabet + Digits (0-9) (+ optionally "!" as the only available Symbol in static passwords).

The 16 characters used in the ModHex alphabet are: c,b,d,e,f,g,h,i,j,k,l,n,r,t,u,v. These characters share a property that makes them very valuable to a YubiKey: They use the same scan codes across a very large number of keyboard layouts. In other words, the scan code 0x06 maps to the character c for English, Swedish, German, French, and many others.

OneTimePasswords (OTP)

Yubico OTP mode

The Yubico OTP mode is AES symmetric key based. On a new YubiKey the Yubico OTP is preconfigured on slot 1. This initial AES symmetric key is stored in the YubiKey and the same AES key is already stored on the Yubico Authentication server. This allows validating against YubiCloud, meaning the use of Yubico OTP in combination with the Yubico Forum website for instance or on https://demo.yubico.com).

The initial configuration and AES key stored in slot 1 can of course be overwritten.

How does it work

Yubikey's authentication protocol is based on symmetric cryptography.
More specifically, each Yubikey contains a 128-bit AES key unique to that device.
It is used to encrypt a token made of different fields such as the ID of the key, a counter, a random number, etc.
The OTP is made from concatenating the ID of the key with this encrypted token.

This OTP is sent to the target system to which we want to authenticate.
This target system asks a validation server if the OTP is good.
The validation server has a mapping of Yubikey IDs -> AES key.
Using the key ID in the OTP, it can thus retrieve the AES key and decrypt the other part of the OTP.
If it looks OK (plain-text ID and encrypted ID are the same, the counter is bigger than the last seen one to prevent replay attacks, then authentication is successful.

The validation server sends that authentication status back to the target system, which grants access or not based on that response.

Security risks

AES key compromise

As you can imagine, the AES key should be kept secret.
It cannot be retrieved from the Yubikey itself (or it should not, at least not with software).
It is present in the validation server though, so the security of this server is very important.

Validation requests/responses tampering

Since the target system relies on the ruling of the validation server, a trivial attack would be to impersonate the validation server.
The target system thus needs to authenticate the validation server.
2 methods are available :

HMAC: This is also symmetric crypto, the target server and validation server share a key that is used to sign requests and responses.

TLS: Requests and responses travel via HTTP, so TLS (HTTPS) can be used to authenticate and encrypt the connection.

YubiCloud and validation servers

When you buy a Yubikey, it is preloaded with an AES key that is known only to Yubico.
They will not even communicate it to you.
Yubico provides a validation server with free unlimited access (YubiCloud).
It also offers open-source implementations of the server.

So you can either:

choose to use your Yubikey with its preloaded AES key and validate against Yubico's validation server ;

or load a new AES key in your Yubikey and run your own validation server.

OATH-HOTP mode (RFC 4226)

Challenge-Response

Function and Application of Challenge-Response

This technic can be used to authenticate.

A challenge is sent to the YubiKey and a response is (auto-magically) calculated and send back.
This calcucation needs a secret (e.g. an AES key in case of the Yubico OTP mode)
The same challenge always results in the same response.
Without the secret this calculation is not meant to be feasable. Even if in the possesion of many (TODO:reference!?) challenge-response pairs.

This can be used for:

true 2-factor (posession and knowledge) authentication:If you combine the response (posession factor) with a password (knowledge factor) and to authenticate you need to present the triple (challenge,response, password) to 3rd party. In which case the challenge and the corresponding response can be (publicly) send to a 3rd party to authenticate the poession factor, by redoing basically the same (auto-magical) calculation. The needed secret needs to be shared with 3rd party to allow an authentication.

semi 2-factor (posession and knowledge) authentication:The challenge can be public. Only with the possession of the YubiKey hardware the response can be generated. This can be used to create a "sort-of" 2-factor authentication (posession and knowledge): If you combine the response (posession factor) with a password (knowledge factor) and use the result for instance as passphrase for cryptsetup.

This functionality will consume one slot. And it is used via API calls to the YubiKey. So you usually use some tool to communicate the challenge to your YubiKey and get back the response.

There are two Challenge-Response modes:

Yubico OTP mode

HMAC-SHA1 mode

Setup the slot

In order to setup slot 2 in challenge-response HMAC mode you probably want to run something like:

Enable the CCID mode

Use OpenPGP smartcard mode

Usecases - putting your YubiKey to good use

YubiKey and cryptsetup encrypted partition/disk

Yubikey can be used to strenghen the security of your cryptsetup encrypted partition/disk (e.g. in LUKS format).

A robust and comfortable to use implementation of a initramfs hook to integrate your yubikey using Challenge-Response (using a static non-private challenge) and optionally a password on top of it can be found here.

keepassx2

keepassxC

keepassxc (see keepassxc.org) a keepassx fork that integrated YubiKey into keepassx v2.The integration covers Challenge-Response as security factor to open the database, but also the generation of OTP using the YubiKey.

Prerequisites

Note: If you are configuring a distant server to use Yubikey, you should open at least one additional, rescue SSH session, so that you are not locked out of your server if the configuration does not work and you exit your main session inadvertently

Note: The following assumes you are using the default Yubico servers. See the yubico-pam documentation for options relevant to using your own server.

Configuration

Authorization Mapping Files

A mapping must be made between the YubiKey token ID and the user ID it is
attached to. There are two ways to do this, either centrally in one file, or
individually, where users can create the mapping in their home directories.
If the central authorization mapping file is being used, user home directory
mappings will not be used and vice versa.

Central authorization mapping

Create a file /etc/yubico/authorized_yubikeys, the file must contain a user name and the
Yubikey token ID separated by colons (same format as the passwd file) for
each user you want to allow onto the system using a Yubikey.

if you are using per-user authorization mapping, where CLIENTID} is your Client ID. This method utilizes your ID and the server's certificate to authenticate the connection.

Note: This will authenticate via Yubico's free YubiCloud servers. If you want to use a different server, add it via the urllist parameter.

Using pure HMAC to authenticate the validation server

Add key to the above lines in /etc/pam.d/sshd:

auth required pam_yubico.so id=CLIENTID key=SECRETKEY ...

where CLIENTID and SECRETKEY are your HMAC ID and key.

You should also disallow unprivileged users to read the file to prevent them from seeing the HMAC credentials:

# chmod o-r /etc/pam.d/sshd

Note: HMAC credentials should be unique to a single target server. That way, if an attacker finds them, he will not be able to craft responses to authenticate to other target servers you own

Using pure HTTPS to authenticate the validation server

Warning: While this "old" method of using a dummy id still works, it is unknown how secure and/or future-proof it is, as Yubico no longer describes it in their documentation. Proceed at your own risk. At the very least you should ensure that only HTTPS servers with valid certificates are used for authentication.

If you do not want to use HMAC credentials from Yubico, it is still possible to authenticate via the Yubico server by setting CLIENTID=1 instead of your own ID. Although pam_yubico's default server uses HTTPS already, for security reasons you should specify it manually via the urllist parameter, as the servers certificate is the only way in which the connection is authenticated. You can find the keyserver URL by adding the debug parameter to the auth line.

SSHD configuration

You should check that /etc/ssh/sshd_config contains these lines and that they are not commented. The sshd_config shipped with openssh has these set correctly by default.

ChallengeResponseAuthentication no
UsePAM yes

That is it!

You should not need to restart anything if you did not change the SSHD config file.

To log in, at the Password: prompt of SSH, you have to type your password without pressing enter and touch the Yubikey's button.
The Yubikey should send a return at the end of the OTP so you do not need to touch the enter key at all.

You can display information about the login data generated by pam_yubico by adding the debug option to the auth line in/etc/pam.d/sshd. However, if you are using a central authorization file, you should remove that option once finished testing, as it causes pam_yubico to display the entire content of the central file to every user who logs in using a Yubikey.

Explanation

This works because the prompt is pam_yubico.so's one, since this module is before pam_unix.so, which normally does basic password authentication.
So, you are giving a string that is the concatenation of your password and the OTP to pam_yubico.so.
Since the OTPs have a fixed length (let us call this size N), it just has to get the last N characters to retrieve the OTP, and it assumes that the other characters at the start are the password.
It tries to validate the OTP, and in case of success, sends the password to the next PAM module. In Archlinux' default PAM stack, the authenticator pam_unix.so is instructed to try receiving a password from the previous module with try_first_pass, so it automatically uses the password sent by pam_yubico.so.

Maintenance / Upgrades

Installing the OATH Applet for a Yubikey NEO

These steps will allow you to install the OATH applet onto your Yubikey NEO. This allows the use of Yubico Authenticator in the Google Play Store.

Note: These steps are only for NEOs with a firmware version <= 3.1.2. The current generation NEOs (with U2F) come with the OpenPGP applet already installed)