This document specifies the Cryptographically Secure Random Number Generator (CSRNG) hardware IP functionality. Due to the importance of secure random number generation (RNG), it is a topic which is extensively covered in security standards. This IP targets compliance with both BSI's AIS31 recommendations for Common Criteria, as well as NIST's SP 800-90A and NIST's SP 800-90C (Second Draft), both of which are referenced in FIPS 140-3. Since these two standards use significantly different terminology, it is recommended that the reader refer to our RNG compliance strategy document for an overview of the various RNG classes and equivalencies between the two standards. The CSRNG IP supports both of these standards for both deterministic (DRNG) and true random number generation (TRNG). In NIST terms, it works with the [Entropy Source IP]({{< relref “hw/ip/entropy_src/doc” >}}) to satisfy the requirements as a DRBG (deterministic random-bit-generator) or NRBG (non-deterministic random bit generator). In AIS31 language, this same implementation can be used to satisfy either the DRG.3 requirements for deterministic generation, or the PTG.3 requirements for cryptographically processed physical generation.
In this document the terms “DRNG” and “TRNG” are used most generally to refer to deterministic or true random number generation functionalities implemented to this specification. However, the terms “DRBG” or “NRBG” are specifically used when respectively referring to SP 800-90A or SP 800-90C requirements. Meanwhile, when addressing requirements which originate from AIS31 we refer to the specific DRG.3 or PTG.3 classes of RNGs.
This IP block is attached to the chip interconnect bus as a peripheral module conforming to the [Comportable guideline for peripheral functionality]({{< relref “doc/rm/comportability_specification” >}}), but also has direct hardware links to other IPs for secure and software-inaccessible transmission of random numbers.
get_entropy_input() interface as defined in SP 800-90A.Block_Cipher_df derivation function (as defined in SP 800-90A) for assembling seed material. This allows the use of entropy sources which are not full-entropy (less than one bit of entropy per bit generated).Though the recommendations in AIS31 are based around broad functional requirements, the recommendations in SP 800-90 are very prescriptive in nature, outlining the exact constructs needed for approval. Thus the interface and implementation are largely driven by these explicit constructs, particularly the CTR_DBRG construct.
The CSRNG IP consists of four main components:
An AES primitive
The CTR_DRBG state-machine (CTR_DRBG_FSM) which drives the AES primitive, performing the various encryption sequences prescribed for approved DRBGs in SP 800-90A. These include:
State vectors for each DRNG instance.
Interface logic and access control for each instance.
Every DRNG requires some initial seed material, and the requirements for the generation of that seed material varies greatly between standards, and potentially between CC security targets. In all standards considered, DRNG's require some “entropy” from an external source to create the initial seed. However, the rules for obtaining said entropy differ. Furthermore the required delivery mechanisms differ. For this reason we must make a clear distinction between “Physical” (or “Live” or “True”) entropy and “Factory Entropy”. This distinction is most important when considering the creation of IP which is both compatible with both the relatively new SP 800-90 recommendations, as well as the well-established FIPS 140-2 guidelines.
Physical entropy is the only type of “entropy” described in SP 800-90. The means of generation is described in SP 800-90B. One statistical test requirement is that physical entropy must be unique between reboot cycles, ruling out sources such as one-time programmable (OTP) memories. In SP 800-90A, the delivery mechanism must come through a dedicated interface and “not be provided by the consuming application”.
Factory entropy is a type of entropy described in the FIPS 140-2 implementation guidance (IG) section 7.14, resolution point 2(a). It can be stored in a persistent memory, programmed at the factory. In some use cases, the consuming application needs to explicitly load this entropy itself and process it to establish the expected seed.
This document aims to make the distinction between physical entropy and factory entropy wherever possible. However, if used unqualified, the term “entropy” should be understood to refer to physical entropy strings which are obtained in accordance with SP 800-90C. That is either physical entropy, or the output of a DRNG which itself has been seeded (and possibly reseeded) with physical entropy. In CC terms, “entropy strings” (when used in this document without a qualifier) should be understood to come from either a PTG.2 or PTG.3 class RNG.