FIDO2 fulfills many authentication gaps PIV was not designed for. FIDO2 enables organizations to use hardware-based MFA to be used in cases where PIV will not work. In this article, we will describe how FIDO2 can be used to offer more authentication services to handle new demands organizations are facing.
FIDO2 vs PIV
FIDO2 is fundamentally different than PIV because it was designed provide a way to deploy hardware/cryptography-based MFA to massive amounts of users. Whereas a large PIV deployment may be 1 million, FIDO2 is designed to be unlimited. Additionally, FIDO2 offers a strong Multi-Factor Authentication (MFA) framework to minimize or replace the use of passwords with scoped public key-based credentials that are resistant to phishing, replay, and server breach attacks. User gestures such as PINs, touch, or biometrics are used to authorize use of FIDO2 credentials Let’s explore how this is possible.
The core difference of FIDO2 is in its trust model. Both FIDO2 and PIV utilize public key cryptography to achieve their core security features. However, FIDO2 establishes trust directly with the end user by using a distributed cryptographic registration and multi-step challenge process for validation instead of an intermediary such as a certificate authority.
Eliminating certificates removed many barriers and finally provided the largest technology providers a realistic way to cost effectively integrate crypto based MFA through the WebAuthN and CTAP protocols. This has resulted in all major browsers and operating systems supporting FIDO2.
How FIDO2 helps Government Agencies
The new features of FIDO2 helps agencies implement authentication in places that were impossible before and help solve serious operational and security challenges. Let’s look at a few examples:
|Eliminate using passwords as workarounds||Instead of using passwords as a backup to PIV, a FIDO2 token can be issued for AAL3 MFA thereby ensuring hardware MFA is always in use to protect resources.|
|Using mobile devices||A FIDO2 credential can be used because it is natively supported on a mobile device and does not require any extra hardware attachments of software.|
|Eliminate travel requirements||Traditional PIV issuance requires additional hardware and software not readily available. FIDO2 was designed to be used out of the box by the operating system and browsers by USB or lightning connectors. This built in compatibility enables organizations to implement remote issuance models where credentials can be encoded with the user’s device without requiring any travel.|
|Reduce operational costs||The direct trust model of FIDO2 helps eliminate many costs related to software maintenance and PKI validation. Additionally, onboarding or issuing alternate tokens can be significantly more cost effective because these processes can now be performed remotely.|
|Richer authentication information||The WebAuthN element of FIDO2 provides additional security features to enable relying parties to obtain greater information when the user is attempting to authenticate. Now agencies can understand more about the person that is attempting to login. Additionally, strong security such as two-step authentication and user-presence can be verified.|
|Faster credentialing||FIDO2 tokens are extremely easy to purchase and are delivered with attestation certificates. These certificates allow the issuer to validate the authenticity of the device even if purchased directly from different retailers.|
FIDO2 Authentication Features for Government
While FIDO2 was developed for the mass consumer, there are extra controls that can be turned on to achieve the extra security controls Government organizations demand. At a high level, the authentication sequence is as follows:
- User requests access to resource
- Resource stipulates MFA access requirements
- User enters PIN, proves they are present by touching the device
- Resource validates credential
- User is authenticated
The highlighted step 2 is very critical. This is where the resource specifies how the authentication should occur. Unlike PIV, there are various settings that can provide much more granularity and authentication information to help ensure the credential should be validated. Some of these configurations are as follows:
- Attestation: The YubiKey attestation certificate can be sent with the authentication request. With this information, the authenticity of the device can be verified regardless of where it was purchased. This is extremely helpful if you have a distributed credential distribution process.
- User presence: Even though the person possessing the YubiKey credential has to enter a PIN, they must also physically touch the device. This is critical because malware can supply a PIN via API and perform signing. This vulnerability is eliminated with the YubiKey because the user must physically touch the device before signing will occur.
- Dynamic MFA requirements: One of the most impressive features is that the server can specify what is required for authentication dynamically. For example, for a high security transaction, the server may enforce that PIN, location, and attestation is required. But for a lower security requirement, the server may just require user presence. This capability enables the designer and security engineer to finely tune both the usability and security requirements.
- Direct Crypto: the client and server interact directly to perform cryptographic operations. There is no slowdown created when doing certificate validation.
How a FIDO2 credential is issued
While the FIDO2 issuance model can implement the same identity proofing requirements as PIV, there is much more flexibility in terms of how the credential is initialized and how the applicant actually can get the AAL3 token. Unlike PIV where the applicant must have a smart card reader, extra software and card specifically sourced from a few vendors, FIDO2 issuance can occur on any device with an AAL3 certified token purchased from countless online retailers. Let’s explore the security controls that enable this flexibility
Attestation Certificate: Hardware providers such as Yubico will embed a certificate into their device during manufacturing time. This enables the credential issuance system to validate the authenticity of the hardware before proceeding.
CTAP: If comparing to PIV, the Client to Authenticator Protocol (CTAP) is similar to the smart card mini-driver and PCKS11 in that it allows the hardware to interact with the software. However, CTAP is being built directly into the iPhones, Droids, Surface Pro devices so that the FIDO2 credential can work without installing any extra software.
Identity Proofing: The FIDO2 credential issuance model can utilize the PIV derived credential protocol in order to use applicant’s PIV credential as a means to prove they have already been verified. If the applicant does not have a PIV credential, FIDO2 uses the identity proofing model where the applicant’s photo, documents, and other identity is first captured and verified before the credential issued.
Using FIDO2 in your organization
Recent advancements in FIDO2 adoption have provided authentication use cases that are extremely relevant to Government organizations. For example, Microsoft recently released guidance for using FIDO2 credentials with Active Directory. Also, large authentication providers such as Duo security support FIDO2. Finally, a FIDO2 credential can be used in the OpenID connect authentication process to give application developers a standard authentication API to use across their organization. The table below shows examples of how FIDO2 can be used immediately.
|Windows logon||Microsoft FIDO2 with Active Directory Configuration Guidance|
|OpenID Connect||If your applications utilize OpenID connect, you can configure them to utilize FIDO2 based authentication|
|Duo Security||If you have a Duo Security deployment, you can link your FIDO2 token to your Duo account.|
The best way to see how FIDO2 can help, is to actually use it. The fastest way to do this is to obtain a YubiKey and then go to https://webauthn.io/ using your iPhone or Droid and click “register”. You will see your mobile device interact with the YubiKey. When I first saw this, I could not believe it.
The next step will be to implement a proof of concept in your organization so you can create and use FIDO2 credentials specific to your organization. To help you accelerate your FIDO2 trial, we have created a package that can allow you to issue and use FIDO2 credentials. The system will allow you to:
- Issue FIDO2 credentials to a YubiKey device
- Authenticate the FIDO2 credential to create an OpenID JWT
- Register your FIDO2 credential with Active Directory to perform FIDO2 logon
End state architecture:
IDP: Issuer of the FIDO Credential
RP: Relying party. This is the resource that is needs authentication to be it grants access. The RP can be Active Directory, a web application, Office365, or a custom API.
Optional: STS: Secure Token Service
Once you understand the basics of FIDO2 and want to move to more advanced usages you can use the IdExchange system to:
- Remote identity proofing at National Institute of Standards and Technology (NIST) Identity Assurance Level 2 (IAL2)
- PIV Derived Issuance
- Provide OpenID Connect Support
- FIDO2 + PIV Token on one Credential
Recap and Resources
FIDO2 is emerging as the easiest way to deploy and use hardware/crypto based MFA. It is based on W3C standards, has wide support amongst the world’s largest technology providers, and most importantly…embraces cryptography as it core for security. Below are great links to help you really learn the inner workings of the specification. Additionally, the table provides more information about the differences between FIDO2 and PIV. I hope you enjoy FIDO2 and put it to work!
|Trust||Direct trust||Uses PKI for trust|
|Interoperability||iPhone, Droid, Microsoft, Browsers, numerous Credential hardware||Windows 10,|
|Context||location, attestation, device type||Not supported|
|MFA options||Touch, PIN||PIN|
|Issuance Time||30 seconds||2 minutes|
|Device validation||Attestation certificate||Not supported|