Achieving FedRAMP Compliance with FEITIAN Technologies

Wed 16 Aug 2023
Home 9 Knowledge Base 9 Achieving FedRAMP Compliance with FEITIAN Technologies

The Federal Risk and Authorization Management Program, or FedRAMP, is a government-wide program that provides a standardized approach to security based on technical requirements from the National Institute of Standards and Technology (NIST). When services or solutions seek compliance with the FedRAMP requirements to interact with federal resources, various authenticator products from FEITIAN Technologies can be selected as part of a larger authentication and identity management framework. 

FedRAMP, at its core, is a program to modernize and apply modern standards of cybersecurity to ensure the sensitive data contained within federal systems remains secure. It achieves this goal by utilizing the guidelines provided in the NIST Special Publications to provide direction on the implementation of such systems. The NIST documents specific to a particular component of an implementation, from identity proofing to user authentication and beyond, should be regarded as the source of truth, and FedRAMP provides the process to ensure the instructions contained within are implemented fully and correctly.  

Due to various combination of authentication options and certification level requirements, some confusion can arise when ensuring compliance with the NIST SP 800-63-3 guidelines and FedRAMP as a whole. This guide addresses the most common questions and offers prescriptive solutions for most FedRAMP scenarios. 

Authenticator Assurance Levels (AALs) 

The available authentication options for FedRAMP compliance will be limited by the required Authenticator Assurance Level (AAL) for the service. AALs are determined by the sensitivity of the interactions between the service and resources, and the required AAL should be defined prior to the design of the user authentication architecture. For guidance on determining the AAL level appropriate for the service, refer to NIST SP 800-63-3, section 6.2

There are three AALs, in rising order of security. These levels are fully defined in NIST SP 800-63B, Section 4

AAL1: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.  

AAL2: AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.  

AAL3: AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifiable impersonation resistance; the same device MAY fulfill both these requirements.  

In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required. 

 Below is a summary (table 4-1) from what’s defined in SP 800-63B Section 4: 

Requirement AAL1 AAL2 AAL3 
Permitted authenticator types Memorized Secret; Look-up Secret; Out-of-Band; SF OTP Device; MF OTP Device; SF Crypto Software; SF Crypto Device; MF Crypto Software; MF Crypto Device MF OTP Device; MF Crypto Software; MF Crypto Device; or Memorized Secret plus one of the following:  Look-up Secret Out-of-Band SF OTP Device SF Crypto Software SF Crypto Device MF Crypto Device; SF Crypto Device plus   Memorized Secret; SF OTP Device plus MF Crypto Device or Software; SF OTP Device plus SF Crypto Software plus Memorized Secret 
FIPS 140 validation Level 1 (Government agency verifiers) Level 1 (Government agency authenticators and verifiers) Level 2 overall (MF authenticators) Level 1 overall (verifiers and SF Crypto Devices) Level 3 physical security (all authenticators) 
*MF – Multi-factor, i.e. two or more forms of authentication must be supplied to use. Examples include PIN locked smart cards. 
*SF – Single-factor, i.e. only one form of authentication must be supplied to use. Examples include passwords. 

Supported Authenticator Types 

Below are the authenticator types and products from FEITIAN Technologies that can help meet the requirements established in NIST SP 800-63B in order to be compliant with FedRAMP.  For compliance with the FedRAMP guidelines, an Authenticator must be FIPS 140-2 certified. 

Memorized Secret (Section 5.1.1)

A Memorized Secret is a string of at least 8 characters in length defined by the user; it is commonly referred to as a password, passphrase or PIN. While a Memorized Secret can be entirely numeric, it should not be confused with a PIN, which is used to validate a Multi-Factor (MF) Cryptographic Device.  

The key difference is a Memorized Secret is validated against the service being authenticated to while a MF Cryptographic Device PIN is validated by the Cryptographic Device itself.  

Single-Factor One-Time Password (OTP) Device (Section 5.1.4)

SF OTP devices generate unique one-use codes (OTPs) via cryptographic algorithms, with the OTP validated by the service being authenticated to. As a Single-Factor device, possession of the SF OTP device is considered sufficient; a user does not need to supply a password or PIN for it to generate an OTP for authentication.  

FEITIAN Technologies provides hardware OTP tokens (following OATH’s open standard) available in event-based HOTP and time-based TOTP models and they are FIPS-140-2 Level 1 certified. 

Single-Factor Cryptographic Device (Section 5.1.7)

Single-Factor Cryptographic (SF Cryptographic) devices perform cryptographic operations using protected symmetric or asymmetric key(s) internally and provide the authenticator output via direct connection to the user’s endpoint, with the output validated by the service being authenticated to. As a Single-Factor device, possession of the SF cryptographic device is considered sufficient; a user does not need to supply a password or PIN for authentication.  

FEITIAN’s Biopass series (k26/k27) supports the FIDO/U2F protocol when being used as an SF Cryptographic Device, and they are FIPS-140-2 Level 2 Certified.  

Multi-Factor Cryptographic Device (Section 5.1.9)

Multi-Factor Cryptographic (MF Cryptographic) devices provide the highest level of user authentication. As a Multi-Factor device, possession of the MF cryptographic device is not considered sufficient; it is required that the user must authenticate to the hardware device with also ‘something you know’ (such as a PIN) or ‘something you are’ (such as biometric) prior to the device allowing user authentication to a service.  

FEITIAN’s Biopass series supports FIDO2 biometric protocol when being used as an MF Cryptographic Device.

Meeting AALs with the FEITIAN Technologies 

Let’s take a look at how different products offered by FEITIAN Technologies can be utilized to meet every AAL level described in NIST 800-63-3, and allow for FedRAMP compliance within your organization.  

AAL1 

AAL1 can be met with FEITIAN’s OATH OTP Hardware tokens as a Single-Factor One-Time Password (SF OTP) device or with the Biopass security keys in FIDO/U2F mode as the Single-Factor Cryptographic Device (SF Cryptographic). As a Single-Factor device, possession of the authenticator (‘What you have’) is considered sufficient to meet the requirements to authenticate the user; no additional password or memorized secret is required. 

A sample deployment to meet AAL1 would be to use the OTP hardware token as SF OTP generating One-Time-Passcodes to prove the possession of the authenticator via cryptographic signature. If the service allows for extended sessions, the user must re-authenticate at least once every thirty days. 

AAL2 

There are several options to achieve AAL2 (the first two are identical to what’s mentioned in above AAL1 section): 

  1. A separate Memorized Secret (password) and a Single-Factor One-Time Password (SF OTP) device such as FEITIAN’s OATH OTP Hardware tokens. The Memorized Secret must be provided to and validated by the service the user is authenticating to; the requirements for the Memorized Secret are defined in NIST SP 800-63B 5.1.1.2 Memorized Secret Verifiers
  1. A separate Memorized Secret (password) and a Single-Factor Cryptographic Device (SF Cryptographic) such as FEITIAN’s Biopass security keys in FIDO/U2F mode.  
  1. Multi-Factor Cryptographic (MF Cryptographic) device – FEITIAN’s Biopass security keys can be configured in FIDO2 Biometrics mode to fulfill the authentication requirement as a MF Cryptographic device as noted in NIST 800-63B section 5.1.9 

A sample deployment to meet AAL2 would be using the FEITIAN’s Biopass FIDO2 Biometric security keys (1st Gen: K26, K27 FIPS-140-2 Level 2 Certified) as an Multi-factor Cryptographic device, which authenticates the user by performing a local, on-device, fingerprint pattern matching ceremony. This establishes the user based on the possession of the security key (“What you have”) as well as the biometric matching (“What you are”).  Once authenticated, If the service allows for extended sessions, the user must re-authenticate at least once every twelve hours. 

AAL3 

FEITIAN’s latest 2nd Gen BioPass FIDO2 security keys (K49/K50) offers two options for meeting AAL3. Both options use the same key as a MF Cryptographic Authenticator, with the authentication process occurring without the user acting as a bridge between the authenticator and endpoint.

Either of these two options meet the requirements of an AAL3 authenticator, but only when used in conjunction with an approved environment which supports a secured implementation of digital authentication, including verifier-impersonation resistance. For example, some Chromium-based web browsers may not support sufficient verifier-impersonation resistance with FIDO2 WebAuthn to qualify for being used in an AAL3 deployment. However, these browsers can provide the required AAL3 level if used with smart cards through mutual TLS (mTLS). Discuss your use cases and requirements with your identity provider vendor as they may have introduced specific controls to meet AAL3 requirements.

AAL3 with PIV Smart Card

AAL3 can be met with the BioPass FIDO2 (K49/50) and ePass FIDO Plus series (K9+, K40+) as a Multi-Factor Cryptographic (MF Cryptographic) device, such as a PIV smart card. The PIV smart card function must have a PIN at least 6 characters in length, and contain a user authentication certificate issued by a FIPS 140-2 validated Certificate Authority linked to the service being authenticated to. As a Multi-Factor Authentication solution, the FEITIAN keys work as a smart card secured with a PIN is sufficient to meet the requirements to authenticate the user.

For example, the BioPass FIDO2 key can be configured as a PIV smart card, identifying and authenticating the user when logging into a site or service. The user authentication certificates stored on the PIV smart card function of the BioPass FIDO2 key would be validated by a Certificate Authority server controlling access to the service, and confirmed to originate from a trusted CA. If the user is inactive for 15 minutes, they must re-authenticate again.

AAL3 with FIDO2 Biometric

FEITIAN’s Gen 2 Biopass FIDO2 keys (K49/50) can be configured in FIDO2 Biometrics mode to fulfill the authentication requirement as a MF Cryptographic device as noted in NIST 800-63B section 5.1.9 with its FIPS-140-2 Level 2 and Physical Security Level 3 certification, it can help achieve AAL3 requirements.

AAL Level Authentication Method(s) Capability Memorized Secret Requirements Products 
SF OTP OATH-TOTP, OATH-HOTP N/A OATH OTP Hardware tokens 
SF Cryptographic Device FIDO U2F N/A Biopass security keys in FIDO/U2F mode 
Password + SF OTP OATH-TOTP, OATH-HOTP 5.1.1.2 Memorized Secret Verifiers OATH OTP Hardware tokens 
Password + SF Cryptographic Device FIDO U2F 5.1.1.2 Memorized Secret Verifiers Biopass security keys in FIDO/U2F mode 
MF Cryptographic Device FIDO2 Biometric N/A 1st Gen Biopass security keys(K26/27) in FIDO2 mode. 
MF Cryptographic Device FIDO2 Biometric  N/A 2nd Gen Biopass security keys (K49/50) in FIDO2 mode
3MF Cryptographic Device PIV
Smart Card (PIV Applet)ePass FIDO Plus (K9+, K40+) and 2nd Gen Biopass security keys (K49/50) in PIV mode

Additional Considerations 

This guide only touches on the methods with which to meet FedRAMP compliance using the existing FEITIAN OTP/FIDO products as an Authenticator. It is important to keep in mind there are other aspects which can impact the certification of a solution, and should be kept in mind when planning/executing the integration. 

The standard includes AAL requirements include 11 categories: 

  • Permitted authenticator types 
  • FIPS 140-2 verification level 
  • Reauthentication 
  • Security controls 
  • Man-in-the-middle (MitM) resistance 
  • Verifier-impersonation resistance (phishing resistance) 
  • Verifier-compromise resistance 
  • Replay resistance 
  • Authentication intent 
  • Records Retention Policy 
  • Privacy Controls 

The remaining categories must be included as part of an overall solution, but are not necessarily part of the authentication process:  

  • Reauthentication 
  • Security controls 
  • Records Retention Policy 
  • Privacy Controls 

As part of a larger discussion, the process in which FEITIAN’s authentication products are initialized and deployed to users should also be considered to ensure compliance. NIST guidelines require the separation of roles between an end user, who uses an authenticator on a day to day usage, and a crypto officer, who is responsible for securely loading the cryptographic secrets onto an authenticator. This can impact some deployments, but also can be easily addressed using systems such as Card Management Solutions (CMS) or having a proper process. 

Related Posts

FIDO U2F Setup Guide for Online Services and Applications

This PDF provides a guide for end-users to enable Two-factor authentication for specific ...

Programming NFC OTP Tokens and Cards on Windows OS

FEITIAN's NFC OTP Token can be programmed to work as offline replacement for the mobile ...

Troubleshooting FEITIAN security keys

Check if the key is powered - if the key is inserted to a USB port, check to see if the LED is ...
Enterprise Security

Stay in the know

Join our community of security-conscious individuals and organizations who prioritize safeguarding their sensitive data. Stay informed about the latest advancements in cyber-physical technology and discover how FEITIAN can empower you to take control of your digital security.

"*" indicates required fields

Full Name*