Are RSA SecurID hardware and software tokens FIPS 140-2 compliant?

[#1]

Article Number

000014376

Applies To

RSA Product Set: SecurID
RSA Product/Service Type: Hardware and software tokens

Issue

Are RSA SecurID tokens FIPS 140-2 compliant?

Resolution

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 RSA 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 token

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.
 

2.  Are SecurID tokens FIPS 197 compliant?

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.
 

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 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.
 

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 FIPS validated cryptography.
• 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.

Additional notes and comments regarding RSA SecurID Software Tokens and all tokens in general

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.