FIPS 140 validation of RSA OTP

[BillFanelli]

FedRAMP requires that OTP authenticators and verifiers use FIPS 140 validated cryptographic modules (CMs) for hashing within OTP products. In Article Number 000014376, RSA Customer Support states that RSA authenticators do not make use of FIPS validated CMs. 

Question: Do RSA verifier products use FIPS validated CMs?

As a side note: Does RSA have plans to make use of FIPS validated CMs in their authenticators?

[RicardoArmand]

Hi Bill,

See KB 000037030 or click here

[BillFanelli]

Ricardo,

That reply is very helpful. It addresses RSA soft token authenticators, and I will pass this information along. 

This KB article seems to undercut the argument made in Article # 000014376 that FIPS 140 does not apply to OTP devices. I would strongly suggest you revise it.

I am also interested in the same level of information regarding FIPS 140 validation on the verifier side.

Bill

[EdwardDavis]

RSA Authentication Manager 8.2 and up, has FIPS-140 complaint cryptographic module for handling OTP codes. 

AM 8.2 includes FIPS-compliant cryptographic library module RSA BSAFE® Crypto-J 6.1

FIPS-certified cryptographic implementations in the server

Internal Authentication Manager communication between the primary instance, the replica instances, and Authentication Manager deployed on the web-tier servers.

Sensitive database records, such as password hashes, PINs, and token seeds, are encrypted and decrypted with FIPs-compliant algorithms.

Web Console interfaces, such as the Operations Console, Security Console, and the Self-Service Console.

Risk-based authentication (RBA).

Dynamic seed provisioning information that is exchanged with the four-pass CT-KIP protocol.

Authentication Manager backup and restore feature encryption.

LDAP connections between Authentication Manager and identity sources.

TCP-protocol network connections, such as an IPv4/IPv6 network connection

The current version of Authentication Manager is 8.4 and has this version and notification in system log on startup:

From the 8.4 release notes: RSA® SecurID Access Release Notes for RSA Authentication Manager 8.4 

https://community.rsa.com/docs/DOC-86255 

[BillFanelli]

Edward,

This is awesome information! I will pass this along to our team. 

So, the last item is the RSA hard tokens. Customer Support Article Number 000014376 says FIPS does not apply. Clearly the soft token and Authentication Manager teams believe it does.

Can you find any documentation on FIPS 140 verified CMs in use in RSA hard tokens?

Thanks in advance,

Bill

[EdwardDavis]

Software Tokens and Authentication Manager server live on an Operating System and device file system, and can be accessed via multiple methods, therefore require more scrutiny to be fully secure, and therefore FIPS-140 tested/certified. Same 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. I think that 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.

I will call this section from the KB article referenced earlier in this same thread:

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.

[BillFanelli]

Edward,

NIST SP 800-63B is very clear that FIPS 140 does apply to both OTP software for hard and soft tokens, as well as the physical packaging of hardware tokens. That article make the statement that "cryptography is not used here in the traditional sense". This is absolutely incorrect. There is a common misunderstanding in the security marketplace that perhaps "encryption is not used for OTP in the traditional sense", but encryption is not all there is to cryptography.

OTP uses hashes. For those hashes to be secure, they must have sufficient cryptographic strength. Cryptographically strong hashing is a very traditional use of cryptography.

Given the above, I would restate the RSA customer support assertion as follows:

In every case, FIPS 140-2 is applicable to hardware and software OTP devices as cryptography is used here in a very traditional sense within the cryptographic modules. In addition, NIST's SP 800-63B places additional requirements on OTP physical packaging that also fits within FIPS 140 and is required for federal government use.

Regards,

Bill