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.
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.
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.
Review the FIPS 140-2 Validation Certificate for the smart chip and OS used in the SID800.
Yes, the algorithm is FIPS compliant. The FIPS 197 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.
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 Governments 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 cross-platform 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 andused in a manner compliant with FIPS 201.
RSA has no current plans to apply for Common Criteria validation of its hardware tokens.
Description of different NIST levels:
RSA SecurID Software Tokens and the Authentication Manager 8.4 server are FIPS-140 compliant, as they are on an operating system and device file system, and can be accessed via multiple methods, therefore require more scrutiny to be fully secure, and, are therefore FIPS-140 tested/certified.
The same is true with the SID800 smartcard storage area, which is accessible over USB.
The SID700 and SID800 tokencode chip is locked down, embedded in epoxy, tamper-evident/tamper-proof, and there is no way to access the chip and future codes without destroying it. Due to the nature of what the hardware token does and how it works, and the fact it is not a cryptographic module, it is not required to be FIPS-140 certified itself.
FIPS 140-2 is not applicable to a SID700 and SID800 tokencode, because they are not cryptographic modules.
Here is the specific language directly from the FIPS 140-2 spec:
This standard specifies the security requirements that will be satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information (hereafter referred to as sensitive information).
The SID700/800 does not store, encrypt, transmit or protect any information, sensitive or otherwise. FIPS 140-2 is applicable to RSA Authentication Manager, because it has a database that stores encrypted customer data. It is applicable to software tokens because they receive encrypted data from Authentication Manager and store encrypted token records in the host OS. And it is applicable to the smart card portion of the SID800 because it is used for both encryption and digital signature operations.