A YubiKey is a small hardware device that offers two-factor authentication with a simple touch of a button. YubiKeys are built strong enough for the largest enterprises, while remaining simple enough for anyone to use. The YubiKey NEO offers both contact (USB) and contactless (NFC, MIFARE) communications. YubiKeys support FIDO U2F, Yubico-OTP, OATH-OTP, OATH-HOTP, OATH-TOTP, OpenPGP, and PIV, and one security key can support an unlimited number of applications without the need for drivers, client software, or batteries.
A single YubiKey has multiple functions for protecting access to your email, your apps and your physical spaces. Use one or more YubiKey features, or use them all. The versatile YubiKey does not require software installation or a battery; just plug it into a USB port, and touch the button for secure and strong authentication. A YubiKey is something you have that provides security protection beyond something you know (like a username/password). Even if someone steals your username and password (which is happening in bunches lately) they can’t get into your account without your physical key.
- Hardened against attacks; anti-phishing features
Mobile devices allow users to install apps, which also provides avenues of attack for malicious entities. Malware installed on a mobile device can compromise the security of its 2FA authentication, and any site or service it protects. SMS authentication is susceptible to man-in-the-middle attacks. YubiKeys, on the other hand, are built to withstand malware, phishing and hacks.
- Simple, automatic entry of one-time password (OTP); no need for manual entry
Time-based hardware tokens, SMS and mobile phone software require the user to physically enter in a code each time they wish to authenticate. YubiKey authentication is completed with one touch of a button or tap via NFC removing user error and allowing for instant entry of longer, more secure OTPs.
- No client software or drivers to install; nothing needed except the key
Other authenticators rely on drivers and client software to complete their solution. YubiKey is a standalone device that acts like a keyboard when it is plugged into a USB port or is used as a contactless device communicating over NFC. The YubiKey is compatible with authentication protocols already supported by many existing applications and services.
- No need to administer time synchronization
Time-based solutions including hardware tokens do not have an easy way to resolve time drifts when the system and token clocks fall out of sync. While the YubiKey can support time-based authentication, the device is not restricted to TOTP. In fact, the YubiKey supports multiple protocols on the same device allowing for the best solution for any situation.
- Near Field Communication (NFC) functionality; contactless support
While some smart cards may offer an NFC option, YubiKey integrates NFC into both OTP and smartcard (CCID) mode. This allows for a greater flexibility for delivering a second factor of authentication. (Note: NFC is available in the YubiKey NEO model only.)
- Can provide a complex static password when 2FA not available
Other authenticators don’t offer this feature, which allows a complex and long password to be used when two-factor authentication is not supported.
- Crush and impact resistant — stands up to abuse
Other authenticators can’t take the same level of abuse as the waterproof, crushproof, and hermetically sealed YubiKey. In addition, the YubiKey does not have a battery or moving parts.
- Designed with the next generation protocol (FIDO U2F) built-in
Other devices are generally single purpose, single protocol authenticators, while YubiKey works with all protocols we support without the need to make any changes to the device or change any configuration. YubiKey supports Yubico-OTP, OATH-HOTP, OATH-TOTP, OpenPGP, PIV, and FIDO U2F.
The YubiKey generates an encrypted password that can only be used once. Hackers require physical access of your YubiKey to generate the OTP. This feature is available on every YubiKey except the U2F Security Key.
The information that makes up a Yubico OTP consists of:
1.The private identity of the YubiKey
2.Counter fields tracking how often the YubiKey has been used
3.A Timer field tracking the time between generating each OTP
4.A Random number to add additional security to the encryption
5.A closing CRC16 checksum of all the fields
Each new OTP may be created from the past OTPs used. An example of this type of algorithm, credited to Leslie Lamport, uses a one-way function (call it f). This one-time password system works as follows:
1.A seed (starting value) s is chosen.
2.A hash function f(s) is applied repeatedly (for example, 1000 times) to the seed, giving a value of: f(f(f( ….f(s) ….))). This value, which we will callf1000(s) is stored on the target system.
3.The user’s first login uses a passwordpderived by applyingf999 times to the seed, that is,f999(s). The target system can authenticate that this is the correct password, becausef(p) isf1000(s), which is the value stored. The value stored is then replaced bypand the user is allowed to login.
4.The next login, must be accompanied by f998(s). Again, this can be validated because hashing it gives f999(s) which is p, the value stored after the previous login. Again, the new value replaces p and the user is authenticated.
5.This can be repeated another 997 times, each time the password will be f applied one fewer times, and is validated by checking that when hashed, it gives the value stored during the previous login. Hash functions are designed to be extremely hard to reverse, therefore an attacker would need to know the initial seed s to calculate the possible passwords, while the computer system can confirm the password on any given occasion is valid by checking that, when hashed, it gives the value previously used for login. If an indefinite series of passwords is wanted, a new seed value can be chosen after the set for s is exhausted.
To get the next password in the series from the previous passwords, one needs to find a way of calculating the inverse function f−1. Since f was chosen to be one-way, this is extremely difficult to do. If f is a cryptographic hash function, which is generally the case, it is (so far as is known) a computationally infeasible task. An intruder who happens to see a one-time password may have access for one time period or login, but it becomes useless once that period expires. The S/KEY one-time password system and its derivative OTP are based on Lamport’s scheme.
In some mathematical algorithm schemes, it is possible for the user to provide the server with a static key for use as an encryption key, by only sending a one-time password.
The use of challenge-response one-time passwords requires a user to provide a response to a challenge. For example, this can be done by inputting the value that the token has generated into the token itself. To avoid duplicates, an additional counter is usually involved, so if one happens to get the same challenge twice, this still results in different one-time passwords. However, the computation does not usually involve the previous one-time password; that is, usually this or another algorithm is used, rather than using both algorithms.
The methods of delivering the OTP which are token-based may use either of these types of algorithm instead of time-synchronization.
The Yubikey generates a six or eight character one-time password (OTP) for logging into any service that supports OATH-HOTP, a strong open authentication standard. The action is event-based, meaning a new one-time password is generated for each event. The OATH-HOTP feature is available on every version of Yubikey except the U2F Security Key.
According to RFC 6238, the reference implementation is as follows:
- Generate a key, K, which is an arbitrary bytestring, and share it securely with the client.
- Agree upon an epoch, T0, and an interval, TI, which will be used to calculate the value of the counter C (defaults are the Unix epoch as T0 and 30 seconds as TI)
- Agree upon a cryptographic hash method (default is SHA-1)
- Agree upon a token length, N (default is 6)
Although RFC 6238 allows different parameters to be used, the Google implementation of the authenticator app does not support T0, TI values, hash methods and token lengths different from the default. It also expects the K secret key to be entered (or supplied in a QR code) in base-32 encoding according to RFC 3548.
Once the parameters are agreed upon, token generation is as follows:
1.Calculate C as the number of times TI has elapsed after T0.
2.Compute the HMAC hash H with C as the message and K as the key (the HMAC algorithm is defined in the previous section, but also most cryptographical libraries support it). K should be passed as it is, C should be passed as a raw 64-bit unsigned integer.
3.Take the least 4 significant bits of H and use it as an offset, O.
4.Take 4 bytes from H starting at O bytes MSB, discard the most significant bit and store the rest as an (unsigned) 32-bit integer, I.
5.The token is the lowest N digits of I in base 10. If the result has fewer digits than N, pad it with zeroes from the left.
Both the server and the client compute the token, then the server checks if the token supplied by the client matches the locally generated token. Some servers allow codes that should have been generated before or after the current time in order to account for slight clock skews, network latencies and user delays.
- K be a secret key
- C be a counter
- HMAC(K,C) = SHA1(K ⊕ 0x5c5c… ∥ SHA1(K ⊕ 0x3636… ∥ C)) with ⊕ as XOR, ∥ as concatenation, for more details see HMAC (C is the message)
- Truncate be a function that selects 4 bytes from the result of the HMAC in a defined manner
Then HOTP(K,C) is mathematically defined by
HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF
The mask 0x7FFFFFFF sets the result’s most significant bit to zero. This avoids problems if the result is interpreted as a signed number as some processors do.
For HOTP to be useful for an individual to input to a system, the result must be converted into a HOTP value, a 6–8 digits number that is implementation dependent.
HOTP-Value = HOTP(K,C) mod 10d, where d is the desired number of digits.
The YubiKey generates a six or eight character time-based one-time password (OTP) (in conjunction with a helper application) for logging into any service (such as Microsoft Cloud accounts, Google Apps, Dropbox, EverNote) that supports OATH-TOTP, a strong authentication standard. A new password is generated at a set time interval, typically every 30 seconds. The OATH-TOTP feature is available on every version of YubiKey except the U2F Security Key.
TOTP is based on HOTP with a timestamp replacing the incrementing counter. The current timestamp is turned into an integer time-counter (TC) by defining the start of an epoch (T0) and counting in units of a time step (TS). For example:
TC = (unixtime(now) – unixtime(T0)) / TS
TOTP = HOTP(SecretKey, TC), where the HOTP algorithm is defined below.
TOTP-Value = TOTP mod 10d, where d is the desired number of digits of the one-time password.
- K be a secret key
- C be a counter
- HMAC(K,C) = SHA1(K ⊕ 0x5c5c… ∥ SHA1(K ⊕ 0x3636… ∥ C)) be an HMAC calculated with the SHA-1 cryptographic hash algorithm
- Truncate be a function that selects 4 bytes from the result of the HMAC in a defined manner
Then we define
HOTP(K,C) = Truncate(HMAC(K,C)) & 0x7FFFFFFF
The Challenge-Response method is best suited for offline validations. Use for Windows, Mac, and Linux computer login. The CR feature is available on every version of Yubikey except the U2F Security Key.
Non-cryptographic authentication were generally adequate in the days before the Internet, when the user could be sure that the system asking for the password was really the system they were trying to access, and that nobody was likely to be eavesdropping on the communication channel to observe the password being entered. To address the insecure channel problem, a more sophisticated approach is necessary. Many cryptographic solutions involve two-way authentication, where both the user and the system must each convince the other that they know the shared secret (the password), without this secret ever being transmitted in the clear over the communication channel, where eavesdroppers might be lurking.
One way this is done involves using the password as the encryption key to transmit some randomly generated information as the challenge, whereupon the other end must return as its response a similarly encrypted value which is some predetermined function of the originally offered information, thus proving that it was able to decrypt the challenge. For instance, in Kerberos, the challenge is an encrypted integer N, while the response is the encrypted integer N + 1, proving that the other end was able to decrypt the integer N. In other variations, a hash function operates on a password and a random challenge value to create a response value.
Such encrypted or hashed exchanges do not directly reveal the password to an eavesdropper. However, they may supply enough information to allow an eavesdropper to deduce what the password is, using a dictionary attack or brute-force attack. The use of information which is randomly generated on each exchange (and where the response is different from the challenge) guards against the possibility of a replay attack, where a malicious intermediary simply records the exchanged data and retransmits it at a later time to fool one end into thinking it has authenticated a new connection attempt from the other.
Authentication protocols usually employ a cryptographic nonce as the challenge to ensure that every challenge-response sequence is unique. This protects against a man-in-the-middle attack and subsequentreplay attack. If it is impractical to implement a true nonce, a strong cryptographically secure pseudorandom number generator and cryptographic hash function can generate challenges that are highly unlikely to occur more than once. It is important not to use time-based nonces, as these can weaken servers in different time zones and servers with inaccurate clocks.
Mutual authentication is performed using a challenge-response handshake in both directions; the server ensures that the client knows the secret, and the client also ensures that the server knows the secret, which protects against a rogue server impersonating the real server.
Challenge–response authentication can help solve the problem of exchanging session keys for encryption. Using a key derivation function, the challenge value and the secret may be combined to generate an unpredictable encryption key for the session. This is particularly effective against a man-in-the-middle attack, because the attacker will not be able to derive the session key from the challenge without knowing the secret, and therefore will not be able to decrypt the data stream.
- Server sends a unique challenge value sc to the client
- Client generates unique challenge value cc
- Client computes cr = hash(cc + sc + secret)
- Client sends cr and cc to the server
- Server calculates the expected value of cr and ensures the client responded correctly
- Server computes sr = hash(sc + cc + secret)
- Server sends sr
- Client calculates the expected value of sr and ensures the server responded correctly
- sc is the server generated challenge
- cc is the client generated challenge
- cr is the client response
- sr is the server response
Smart cards contain a computer chip that brokers data exchanges. These same features are contained in the YubiKey 4 and YubiKey NEO, based on the industry standard Personal Identity and Verification Card (PIV) interface over the CCID protocol, which supports PIV on a USB interface.
The YubiKey supports the Personal Identity Verification (PIV) card interface specified in NIST SP 800-73 document “Cryptographic Algorithms and Key Sizes for PIV”. This enables you to perform RSA or ECC sign/decrypt operations using a private key stored on the smartcard, through common interfaces like PKCS#11.
Yubikey PIV info:
- Supports four key slots: PIV Authentication, Digital Signature, Key Management, and Card Authentication.
- Each slot is capable of holding an X.509 certificate, along with its accompanying private key.
- Supports key sizes up to RSA 2048, or ECC secp256r1 keys.
- All functionality is available over both contact and contactless interfaces.
In the physical world, documents and data are often validated with a signature. In the virtual world, OpenPGP is a standards-based public key cryptography for signing, encrypting, and decrypting texts, e-mails, files, etc.
In cryptography, the OpenPGP card is an ISO/IEC 7816-4, -8 compatible smart card implementation that is integrated with many GnuPG functions. Using this smart card, various cryptographic tasks (encryption, decryption, digital signing/verification, authentication etc.) can be performed. It allows the storage of secret key material in a secure manner; all versions of the protocol state, “Private keys and passwords cannot be read from the card with any command or function.” However, a new key pair may be loaded onto the card at any time, overwriting the existing one.
An emerging standard from the FIDO Alliance for applying two-factor authentication to any number of web-based applications, such as Gmail. Works via the browser, Chrome today, Firefox under development) and does not require any drivers. Does not require any client software or drivers.
- Strong security — Strong two-factor authentication, using public key crypto and with native support in the browser (starting with Chrome). Protects against phishing, session hijacking, man in the middle, and malware attacks.
- Easy to use — Works out-of-the-box, enabling instant authentication to any number of services. No codes to re-type and no drivers to install.
- High privacy — Allows users to choose, own and control their secure online identity. Each user can also choose to have multiple identities, including anonymous (no personal information associated with the identity). A U2F device generates a new pair of keys for every service, the public key is only stored on the specific service it connects to. With this approach no secrets are shared among service providers, and even low-cost U2F devices can support any number of services.
- Multiple choices — Designed for existing phones and computers, for many authentication modalities (keychain devices, mobile phone, fingerprint reader, etc.) and with different communication methods (USB, NFC, Bluetooth).
- Interoperable — Open standard backed by leading internet and financial services, including Google, Bank of America and 250 companies in the FIDO Alliance. U2F allows every service provider to be their own identity provider, or optionally let users authenticate through a federated service provider.
- Cost-efficient — Service providers do not have to take the cost and support of secure distribution of U2F devices. Users can choose from a range of low-cost devices from multiple vendors, available at Amazon and other retail stores worldwide. Yubico offers free and open source server software for back-end integration.
- Electronic identity – For services requiring a higher level of identity assurance, services are being developed, both online and in the physical world, for tying your U2F device to your real identity.
- Secure recovery — It is recommended that users register at least two U2F devices with every service provider, which may optionally also provide the user with a backup code should a U2F device be misplaced.
This diagram explains the basic process flow of U2F:
The purpose of the U2F attestation is simply to provide a mechanism so that a U2F relying party (a website or service) can verify the authenticity of a U2F authenticator and thereby trust its attestation certificate. A relying party queries the attestation certificate to find out information about an authenticator, such as a YubiKey. The information queried can include the vendor, the type of device, and the assurance/security properties (for example, a secure element-based device) of the authenticator. The authenticity of the attestation information is guaranteed by a digital signature which has a specified validity period.
In addition to attesting to the authenticity of a device, the attestation certificate can also be used to determine what devices can be used by a relying party. For example, a banking site might want users to be able to provide their own U2F devices for two-factor authentication, but will only allow users to use devices from certain approved vendors.
There are no requirements however to dictate what type of device or client side software is using U2F – the relying party or service can decide to accept any type of attestation certificate or a specific type.
A basic Yubikey feature that generates a 38-character static password compatible with any application log-in. It is most-often used with legacy systems that cannot be retrofitted to enable other 2nd factor authentication schemes, such as pre-boot login. Static password is available on every version of YubiKey except the U2F Security Key.
Yubico’s first go at this was to take the existing OTP functionality and strip out the “one-time” part. That meant freezing the internal counters, timer values, and so on, causing the same algorithm that generates a new OTP each time to generate a single password that doesn’t change. This approach had some problems. First off, the password can’t be stored directly since it’s the result of several parameters that are programmed into the YubiKey. If these parameters are lost, you can’t program another YubiKey with the same password. A second issue is that the generated passwords only use the ModHex alphabet, which uses 16 different lowercase characters. While this is a perfectly safe password to, many applications mandate the inclusion of specific classes of characters, including mixed case, numbers, symbols, and so on. Even worse, many applications limit the size of passwords in length, disallowing the static OTPs due to their length of 32 (or more) characters. We worked around some of these issues by allowing shorter passwords, and doing some basic transformations to the output to ensure there is at least one symbol, one number, and one uppercase character. The issue to freely set your own password remained, and thus we added another mode of operation: scan code mode.
Scan mode allows user to type in his wanted password, and conversion is done to the modhex alphabet itself. However, as Yubikey behaves as a HID, it will still depend on keyboard layout.
3.1. Casing: Not so much tamper-proof
As it turned out, casing is not so much tamper-proof.
Usually vendors go with chemical-resistant epoxy compounds, capacitive sensors, temperature sensors, light sensors and similar stuff. YubiKey used some standard pressure molding polyamide (or something like this) plastic, that is easily dissolvable in acetone.
After giving an acetone bath, it was a perfectly clean PCB in 30 minutes.
On the bottom of the container, there was a settled down milky-gray solution. It was some kind of white powdery which looks like a fiber reinforcement material added to plastic to improve its rigidity.
Contrary to Yubico’s claims, Yubikey appears to be quite destructible. Do not push on it when you touch the sensor while the key is plugged in to a USB port. The point where it bends the most happens to be the point where USB vias are located and through which NFC antenna loop goes. To make things worse, the injection molding hole right next to the connector makes this area even more susceptible to bending.
It is also not recommended to attach a Yubikey to a key ring. The ring hole sits dangerously close to the edge of the PCB. The NFC antenna loop passes between the hole and the edge. Considering that Yubico-chosen plastic is easily scratchable, it will eventually wear off to the point where NFC antenna could be damaged. You may also want to be gentle when connecting or disconnecting the key. After a few hundred times of plugging it in and out, the plastic will get thinner and the key might start falling out or losing connectivity.
It is a perfect solution for those who care about security. More and more providers support U2F authentication that adds security to current used passwords.
Yubikey also have OTP and static password possibility for systems, that does not support U2F yet. OTP can be implemented to any site or software using YubiCloud or own standalone authentication server.
In order to have offline secure authentication – challenge-response authentication may be used. All those features are bundled in one usb key, that could be easily attached to a key chain.
If You had that, You wouldn’t have to care so much about Your password getting keylogged, malware leaked or looked through the shoulder.