The cryptographic module uses the CTR_DRBG,
not the withdrawn Dual_EC_DRBG. The Dual_EC_DRBG was withdrawn in 2014, but this Security Policy for this module was submitted well past that for FIPS 140-2 revalidation, and the CMVP would not have let a testing lab submit it at all.
> Irrelevant
Except it was relevant as a response to the OP in that: I was pointing out their conflation of two different DRBGs.
Having an SP 800-90A DRBG does not mean you support all of them, nor does it imply the user could change between the 3 (or, in that hypothetical, 4).
Outside of that, it is unlikely that this module had Dual_EC_DRBG at any point in time for three reasons:
1) Submitting a hardware module that has an entirely new DRBG would require a lot of low level work from Cavium, and the modifications made to the physical module would likely constitute more than an updated certificate (i.e., a new certificate).
2) Even though the DRBG was withdrawn, the CAVP lists algorithm certificates, and this includes historic certificates. Cavium doesn’t have a Dual_EC_DRBG certificate for any operating environment. A list of Dual_EC_DRBG certificates can be seen here: https://csrc.nist.gov/projects/cryptographic-algorithm-valid...
3) the earliest security policy for the module that I could find dates back to 07/22/2014, and it still uses the CTR_DRBG. Security policy here: https://csrc.nist.rip/groups/STM/cmvp/documents/140-1/140sp/...
The cryptographic module uses the CTR_DRBG, not the withdrawn Dual_EC_DRBG. The Dual_EC_DRBG was withdrawn in 2014, but this Security Policy for this module was submitted well past that for FIPS 140-2 revalidation, and the CMVP would not have let a testing lab submit it at all.
This isn’t the back door.