Hardware security tokens are small physical devices that can authenticate a user's identity and are often used as a form of multi-factor authentication (MFA). One attraction of these devices is that they make MFA relatively simple: just stick in your USB security token and activate it, or, even easier, just bring it near an NFC-enabled device.
In part one of this series, "Security Concerns for Hardware Security Tokens", we discussed the potential risks of using hardware security tokens, and how they could create a false sense of security. We covered how some common misconfigurations could allow bypass. In part two of this topic, we will examine the protocols that hardware security tokens use and uncover more potential risks of poor implementation.
Hardware Token Protocols: What Are The Options?
Let's start off by covering some of the basic protocols that hardware security tokens are capable of. In this case, we will specifically example the Yubikey 5 series of tokens because they are a modern and popular example of the hardware.
The YubiKey 5 Series provides applications for OATH, OpenPGP, Yubico OTP, and Smart-Card and the token determines which protocol to use based on the application or service that the user is accessing. When a YubiKey is connected via USB it sends information including the Vendor ID (VID), Product ID (PID), and other device descriptors that allow the host to identify which protocols are available. Here are the most commonly used protocols.
Yubico OTP Protocol
The default protocol for the YubiKey, if it does not detect a specific protocol request, is the Yubico One-Time Password (OTP) protocol. OTP obtains the system time and generates a unique string based on a secret key stored on the device, a counter, and the system timestamp.
Each Yubico OTP output consists of three sections:
Public Identity: The first 12 characters of the OTP output represent the Public Identity (or Public Key) of the YubiKey. The Public Identity is unique to each YubiKey used to associate the specific YubiKey with an account or service. In the example above, the Public Identity is 'cccjgjgkhcbb'.
OTP: The next 28 characters represent the One-Time Password. The OTP is unique and generated by the private key stored on the YubiKey, a counter, and the current system timestamp. In the example above, the OTP is 'irdrfdnlnghhfgrtnnlgedjlftrb'.
CRC: The last 4 characters of the OTP are a cyclic redundancy check (CRC) used for the recipient to verify the integrity of the OTP string to prevent tampering. In the example, the CRC is 'deut'.
OTP is the most basic protocol and bare minimum in terms of hardware security token security. It is little more than an automated MFA OTP similar to those provided by authenticators such as Google Authenticator. This means OTP is susceptible to man-in-the-middle attacks and real-time replay attacks and phishing similar to the 6-digit OTP codes we are all familiar with.
FIDO Universal 2nd Factor (U2F)
U2F uses a more advanced method of public-key cryptography and symmetric cryptography to secure the authentication process. Specifically, each U2F security key has a unique curve P-256 Elliptic Curve Cryptography (ECC) key pair which is based on the elliptic curve known as secp256r1.
Furthermore, the U2F private key is protected with AES encryption and U2F uses TLS to establish a secure channel between the online service or application and the U2F security key. This ensures that the authentication process is protected from man-in-the-middle attacks and other types of security threats.
The U2F security key also contains a public certificate that is signed by a trusted certificate authority (CA). When the U2F security key is used for authentication, the online service or application verifies the certificate chain to ensure that it is authentic and has not been tampered with.
FIDO2 further builds on the capabilities of U2F and provides a broader set of capabilities and use cases, including support for biometrics. FIDO2 also uses ECC for key generation and exchange between the client (e.g., a web browser) and the FIDO2 authenticator (e.g., a security key) and HMAC-based One-Time Password (HOTP) and Time-based One-Time Password (TOTP) algorithms for symmetric cryptography. FIDO2 also includes support for Transport Layer Security (TLS) and Channel Binding, which provide additional security measures to protect against man-in-the-middle attacks and other types of security threats.
FIDO2's native support for channel binding is implemented by CTAP (Client-to-Authenticator Protocol), which allows direct protected communication with a client device (such as a web browser) and the FIDO2-enabled authenticator device. FIDO2 is also designed to work with a wider range of devices and platforms, including mobile devices and web browsers, making it more versatile and flexible than U2F.
The FIDO2 protocol is also at the core of the WebAuthn standard and provides the underlying mechanisms for secure, passwordless authentication with websites. Altogether, FIDO2's cryptographic mechanisms make FIDO2 the most secure and advanced PKI-based authentication protocol that is resilient against all forms of replay attacks and man-in-the-middle (MiTM) attacks.
What is WebAuthn?
Especially critical to strong hardware token-based authentication is how FIDO2 and WebAuthn work together. WebAuthn (Web Authentication) is a standard for public key cryptography-based authentication created by the World Wide Web Consortium (W3C) that allows websites and applications to implement authentication using hardware security tokens, biometric scanners, and other device based.
WebAuthn is a relatively new standard only having been released in March 2019. The newly developed authentication "Passkey" protocol jointly developed and supported by Apple, Google, and Microsoft uses WebAuthn, and WebAuthn is already supported by major web browsers including Chrome, Firefox, Safari, and Edge.
WebAuthn functionality integrates directly with most web browsers.
How Does FIDO2 + WebAuthn Prevent MFA Phishing Attacks?
WebAuthn capabilities are built right into each browser. Similar to how SSL/TLS certificates can verify a secure connection between the browser and the domain that is displayed in the browser URL bar, FIDO + WebAuthn implement domain binding to ensure that the domain requesting authentication is clearly displayed and also that the provided PKI credential is only valid for the intended domain.
This means that the user can clearly see the domain they are authenticating to, and even if an attacker manages to obtain a user's authentication credential, they would not be able to use it on other websites. WebAuthn clearly displays the domain binding target
FIDO2 and WebAuthn offer the strongest security token-based authentication by far and are protected against MiTM and real-time phishing attacks. The limitations of the hardware security token-based OTP protocol essentially mean that it should never be used in critical security situations. Spoofed websites and MFA exhaustion attacks have proven to be effective methods for extracting OTP codes from users and could lead to breaches that are effectively prevented by the stronger FIDO2 + WebAuthn combo.
FIDO U2F has several limitations compared to the FIDO2 standard including limited support across different platforms and devices and lack of integration with WebAuthn. While it is widely supported on desktop browsers, U2F is not compatible with all mobile devices or applications, while FIDO2, is designed to be platform-agnostic and can be used across various devices, including desktops, mobile devices, and IoT devices, and most importantly integrates with WebAuthn to provide authentication that is directly tied to a services specific web-domain.
Looking for more information on advanced concerns for hardware security tokens? Reach out to our team today or download our Buyer's Guide today for in-depth cybersecurity solution recommendations.