1. Are SecurID tokens FIPS 140-2 compliant?
FIPS 140-2 is a NIST standard that specifies requirements for cryptographic modules. When referring to FIPS 140-2 compliance, it is important to distinguish between the SecurID processor found in all RSA hardware authenticators and the smart chip used specifically in the SID800.
? FIPS 140-2 for SecurID tokens ? In general, FIPS 140-2 is not applicable to hardware OTP devices as cryptography is not used here in the traditional sense. Some people have pointed to the FIPS
140-2 requirement around random number generation (RNG), but SecurID does not use RNG in this way (SecurID can't be a random number or there would be no way for token and server to derive the same value). Others have pointed out the FIPS requirement for performing a Power-On Self Test (POST). Unlike an event-based token that is "powered on" with each button press, however, SecurID time-based tokens are always on and are therefore not subject to this requirement. It is worth noting that RSA does perform an initial POST in manufacturing when the
token is first powered on and programmed.
? FIPS 140-2 for the SID800 ? Although the SID800 itself is not FIPS certified, it is designed to operate in "FIPS mode" using both a smart chip and operating system that are independently certified to FIPS 140-2 level 3.
The FIPS certificate for the smart chip and OS used in the SID800 can be found here -
2. Are SecurID tokens FIPS 197 compliant?
Yes, the algorithm is FIPS compliant. The FIPS197 standard is synonymous with the Advanced Encryption Standard (AES) algorithm which SecurID utilizes. We do not submit our tokens for FIPS certification so they are not certified but the algorithm would pass the test.
3. Are SecurID tokens FIPS 201 compliant?
FIPS 201 is a NIST standard specifying both technical requirements and best practices for deploying
and using smart cards. While originally intended for the US Federal Government?s HSPD-12 program,
widespread interest in FIPS 201 has emerged both in the US and overseas. Many customers initially
ask about the FIPS 201 concept of a Personal Identity Verification (PIV) applet, which promises crossplatform
standardization of smart cards and middleware. What most customers don?t realize, however,
is that the PIV applet specification was written specifically for the needs of the HSPD-12 program and
is far too restrictive for most Enterprise and Commercial users as it forbids any kind of end user self
service and imposes specific requirements for certificate and biometric use. What most customers
actually want is to employ the policies and best practices of FIPS 201 without being limited by the
restrictions of the PIV applet. The SID800 does not support the PIV applet, but can be deployed and
used in a manner compliant with FIPS 201.
4. Do RSA hardware authenticators comply with Common Criteria requirements? If so, what Evaluation Assurance Level (EAL) has been obtained?
RSA has no current plans to apply for Common Criteria validation of its hardware tokens.
5. Are SecurID Tokens NIST 800-63 compliant? Which level of compliance do they meet?
Description of different NIST levels:
? Level 1 requires no identity proofing and allows any type of token, including a simple PIN. Little
effort to protect the session from offline attacks or eavesdroppers is required.
? Level 2 requires some identity proofing. Passwords are accepted, but not PINs. Attacks and
eavesdropping are prevented using cryptographic methods meeting Federal Information Processing
Standard 140-2 requirements.
? Level 3 requires stringent identity proofing and multi-factor authentication, typically a password or
biometric factor used in combination with a software or hardware token, in addition to FIPSvalidated
? Level 4 is the highest level of assurance, requiring multi-factor authentication with a hardware
token. Cryptography in the hardware token must be validated at FIPS 140-2 level 2 overall, with
level 3 validation for physical security. Critical data being transferred must be authenticated with a
key generated by the authentication process.
SD520 is close to meeting the Level 4 criteria. Because the device is always on, it does not perform a
powered on self test (POST) but meets the spirit of all of the Level 4 requirements. All other RSA
hardware authenticators meet NIST Level 3.