1 Introduction

The security of cryptographic systems is based on secret bits and keys. To prevent guessing, these bits need to be random, so they come from true random number generators (TRNGs).

As a fundamental security function, the generation of random numbers is governed by numerous standards and technical requirements. This work describes an architecture and approach that can be taken by CPU designers to address these challenges.

RISC-V (https://riscv.org/) is a popular open-source instruction set architecture (ISA) that anyone can freely use. The minimalistic base instruction sets RV32I and RV64I (for 32- and 64-bit architectures) are often amended with extensions that provide features such as floating-point arithmetic or bit manipulation.

1.1 The RISC-V process

Anyone can build experimental and proprietary systems around RISC-V, but the official, shared ISA specifications are created by committees and task groups within the RISC-V International. The specifications are contributed to the ISA under a permissive open source license. The architecture and interfaces discussed here are in the official RISC-V ratification track [31].

This work grew out of the efforts by individual members of the Cryptographic Extensions Task Group and represents their personal opinions only; not their respective employers or RISC-V International. An ISA specification has limited space to present the considerations and research that led to particular engineering choices. This paper hopes to offer additional rationale to support the RISC-V standardization process.

1.2 TRNG standards and terminology

A driving design goal for our architecture was for it to be easy to implement, yet compatible with current versions of FIPS 140-3 [41] and NIST SP 800-90B [51], significantly updated standards that are only coming into use in the 2020s. Naturally, the architecture should also support other RNG frameworks such as German AIS 20/31 [26, 27], which is widely used in common criteria evaluations. These standards set many of the technical requirements for the design, and we use their terminology if possible.

1.2.1 Physical entropy source (ES)

We will only consider physical sources of true randomness in this work. When they meet certain design criteria, they may be used as entropy sources (ES) for cryptographic purposes [51]. Entropy sources are built by sampling and processing data from a noise source (Sect. 6.1). Since these are directly based on natural phenomena and are subject to environmental conditions (which may be adversarial), they require features that continuously monitor the “health” and quality of those sources. See Sect. 5.3 for a discussion about such security controls.

For the purposes of FIPS 140-3 certification, entropy sources will soon have a separate ENT [42] scope.Footnote 1 Hence, it makes sense to separate the entropy source in the RISC-V architecture too, and simply define an interface for it. System designers who do not have the time or resources to create and certify entropy sources can simply license a compliant IP core and use it.

1.2.2 Conditioning

Raw physical randomness (noise) sources are rarely statistically perfect, and some generate very large amounts of bits, which need to be “debiased” and reduced to a smaller number of bits. This process is called conditioning. A secure hash function is an example of a cryptographic conditioner. It is important to note that even though hashing will make the output look statistically more random, it does not increase its entropy content.

Non-cryptographic conditioners and extractors such as von Neumann’s “debiased coin tossing” [54] are easier to implement efficiently but may reduce entropy as well as redundancy (cryptographic hashes mix the input entropy very efficiently to output bits). However, they do not require cryptanalytic or computational hardness assumptions and are therefore inherently more future-proof. See Sect. 6.3 for a more detailed discussion.

1.2.3 Pseudorandom number generator (PRNG)

Pseudorandom number generators (PRNGs) use deterministic mathematical formulas to create abundant random numbers from a smaller amount of “seed” randomness. PRNGs are divided into cryptographic and non-cryptographic ones.

Non-cryptographic PRNGs, such as LFSRs and the linear-congruential generators found in many programming libraries, may generate statistically satisfactory random numbers but must never be used for cryptographic keying. This is because they are not designed to resist cryptanalysis; it is usually possible to take some output and mathematically derive the “seed” or the internal state of the PRNG from it. This is a security problem since knowledge of the state allows the attacker to compute future or past outputs.

1.2.4 Deterministic random bit generator (DRBG)

Cryptographic PRNGs are also known as deterministic random bit generators (DRBGs), a term used by SP 800-90A [7]. A strong cryptographic algorithm such as AES [37] or SHA-2/3 [38, 39] is used to produce random bits from a seed. The secret seed material is much like a cryptographic key; determining the seed from the DRBG output is as hard as breaking AES or a strong hash function. This also illustrates that the seed/key needs to be long enough and come from a trusted entropy source. The DRBG should still be frequently refreshed (reseeded) for forward and backward security.

1.3 RISC-V target considerations

One of the key features of RISC-V is that essentially the same instruction set can be used on a wide range of application platforms. We identify two broad targets for the TRNG ISA: secure microcontrollers and Linux profile systems.

1.3.1 Secure microcontrollers

Some RISC-V cores are being designed specifically for smart cards and other secure elements, where a hardware-based random number generator is the only viable source of keying material. These “security chip” targets have stringent engineering requirements in relation to RNG quality and certification, physical security, energy efficiency, and unit cost.

Configuration: Embedded-style CPUs may be permanently in machine mode [55], and therefore run only trusted firmware. They are likely to have an RV32 single-hart configuration.

API Interfaces: These targets are expected to interface and implement the TRNG subsystem via a cryptographic library or security-oriented runtime firmware.

1.3.2 General-purpose Linux

We expect Linux and BSD-style operating system kernels to be important in the mobile, desktop, and server application areas. Some of these targets also need to be hardened against invasive physical attacks. Energy efficiency is a concern for mobile devices. Additional entropy sources may be available.

Configuration: These higher-performance CPUs support privilege separation and memory management. They are more likely to be in RV64 multi-hart or even multiprocessor configuration.

API Interfaces: Generally, the TRNG interface will be via the operating system kernel and hypervisor [56]. The Linux kernel conditions input entropy via a multi-source random pool and makes it available to users through /dev/[u]random and getrandom(2).

2 The entropy source interface

The proposed RISC-V TRNG ISA is primarily an entropy source (ES) interface. An implementation with a physical noise source can be used to seed standard and nonstandard cryptographic DRBGs of virtually any state size and security level.

The purpose of this baseline specification is to guarantee that a simple, device-independent driver component (e.g., in Linux kernel, embedded firmware, or a cryptographic library) can use the ISA instruction to generate truly random bits.

Fig. 1
figure 1

The seed CSR (control and status register) provides an entropy source (ES) only, not a stateful random number generator. As a result, it can support arbitrary security levels. Cryptographic (AES, SHA-2/3) ISA extension instructions can be used to construct high-speed DRBGs that are seeded from the entropy source

Full size image

The delineation of various components is illustrated in Fig. 1. This ISA interface does not have to be the only entropy sourcing mechanism. IO interfaces and custom (vendor-provided) drivers can be used for external hardware sources, for example.

2.1 The “seed” register

The main ISA-level interface consists of a single CSR (Control and Status Register), seed (address 0x015), that returns a 32/64-bit value. Polling can be done with:

csrrw rd, seed, x0 // read-write

operation

It is available in machine mode and optionally in other modes (Table 4). See access control Sect. 5.1. M-mode may be the only mode of a microcontroller.

This is an atomic write instruction to guarantee a refresh. Attempts to read (“peek”) without causing a write will trap with an illegal instruction exception.

Table 1 The seed CSR (CSR address 0x015)
Full size table

The instruction is non-blocking and returns immediately, either with two status bits seed[31:30] = OPST set to ES16 (10), indicating successful polling, or with no entropy and one of three polling failure statuses BIST (00), WAIT (01, or DEAD (11). See Table 2.

Table 2 Status bits in the atomic seed CSR output word
Full size table

The sixteen bits of randomness in entropy (located in seed[15:0]) polled with ES16 status must be cryptographically conditioned before they can be used as SSPs (sensitive security parameters) or keying material. We suggest entropy output to be post-processed in blocks of at least 256 bits, with a 128-bit resulting output block. See Sect. 4 for seed requirements.

When OPST is not ES16, seed should be set to 0. An implementation may safely set reserved and custom bits to zeros. A polling software interface should ignore their contents.

2.2 Operational state

As an encoding example for Tables 1 and 2, the value 0x8000ABCD is a valid ES16 status output on RV32, with 0xABCD being the seed value.

In typical implementations, BIST will last only a few milliseconds, up to a few hundred. If the system returns temporarily to BIST from any other state, this signals a non-fatal (usually non-actionable) self-test alarm. BIST is also used to signal test mode (mnoise, Sect. 3).

WAIT is not an error condition and may (in fact) be more frequent than ES16 since physical entropy sources may not have very high bandwidth. The polling can be opportunistic (e.g., a system watchdog interrupt).

The DEAD state indicates a hardware fault, a security issue, or (extremely rarely) a type-1 statistical false positive in the continuous testing procedures. In case of a fatal failure, an immediate lockdown may also be an appropriate response in dedicated security devices.

Figure 2 illustrates operational state (OPST) transitions. The state is usually either WAIT or ES16. To guarantee that no sensitive data is read twice and that different callers do not get correlated output, we suggest that hardware implements “wipe-on-read” on the randomness pathway during each read (successful poll). For the same reasons, only complete and fully processed random words shall be made available via seed.

Fig. 2
figure 2

Normally the operational state alternates between WAIT (no data) and ES16, which means that a 16-bit random seed has been polled. BIST (Built-in self-test) only occurs after reset or to signal a non-fatal self-test alarm (if reached after WAIT or ES16). DEAD is an unrecoverable error state. In test mode (when GetNoise / mnoise is active), WAIT and ES16 states are unavailable in the seed CSR

Full size image

2.3 Interface rationale and discussion

An entropy source does not require a high-bandwidth interface; a single DRBG source initialization only requires 512 bits (256 bits of entropy), and DRBG output can be shared by any number of callers. Once initiated, a DRBG requires new entropy only to mitigate the risk of state compromise.

A blocking instruction may be easier to use, but most users should be querying a (D)RBG instead of an entropy source. Without a polling-style mechanism, the entropy source could hang for thousands of cycles under some circumstances. Mechanisms based on the pause and wfi instructions allow energy-saving sleep on MCUs and context switching on higher-end CPUs.

The reason for the particular OPST two-bit mechanism is to provide redundancy. The “fault” bit combinations 11 (and 00) are more likely for electrical reasons if feature discovery fails and the entropy source is actually not available (this has happened to AMD [49]).

The 16-bit bandwidth was a compromise motivated by the desire to provide redundancy in the return value, some protection against potential Power/EM leakage (further alleviated by the 2:1 cryptographic conditioning discussed in Sect. 4), and the desire to have all of the bits “in the same place” on both RV32 and RV64 architectures for programming convenience.

3 GetNoise test interface

For testing purposes, it is necessary to verify that the noise source and sampler output match their stochastic models. This is often done in a laboratory setting since NIST SP 800-90B [51] requires that the noise source is protected in production devices. They also present a conceptual interface called GetNoise. This is not a name of an instruction or pseudoinstruction.

The custom, but recommended mnoise CSR interface allows access to “raw noise” and is mainly intended for manufacturer tests. It is must not be used as a source of randomness or for other production use. Its contents and behavior are interpreted in the context of mvendorid, marchid, and mimpid CSR identifiers.

The interface consists of a custom, mnoise machine-mode CSR. It is defined mainly so that noise sampling scripts can be written.

The Crypto ISE defines the semantics of only a single bit, mnoise[31], which is named |NOISE_TEST|. Hence, the only universal function of the CSR is for enabling/disabling this interface. This is because the test interface effectively disables seed; this way, a soft reset can also reset this feature. See Fig. 2 for a state transition diagram.

When |NOISE_TEST = 1| in mnoise, seed must not return anything via ES16; we recommend that it is in BIST state. When |NOISE_TEST| is again disabled, the entropy source shall return from BIST via a zeroization and self-test mechanism (effectively a reset).

When not implemented (e.g., in virtual machines), mnoise can permanently read zero (0x00000000). IF available, but with |NOISE_TEST = 0|, mnoise can return a nonzero constant but no noise samples.

The behavior of other input and output bits is left to the vendor. Although not used in production, we recommend that the mnoise read operation is always non-blocking.

4 Entropy source requirements

The ES16 entropy output from the seed CSR is not necessarily fully conditioned randomness due to hardware limitations of smaller, low-powered implementations. However, minimum requirements are defined. A caller should not use the output directly but poll twice the amount of required entropy, cryptographically condition (hash) it, and use that to seed a cryptographic DRBG.

RISC-V requires drivers to implement at least 2-to-1 cryptographic post-processing in software with the expectation that the final output from this post-processing would have “computationally bounded full entropy.”

The expectation is that seed output passes typical randomness tests (e.g. [46]), but weak, pseudorandom, and non-robust sources can pass such tests as well. The results of standard statistical tests should not be confused with amount of entropy available, or the consistency of output. Modern cryptologic evaluation of entropy sources involves an investigation of the stochastic model of the noise source, an analysis of the conditioning component, its health tests, etc.

Three Options. The specification of RISC-V entropy source requirements is complicated by the existence of two major, slightly conflicting standards: NIST SP 800-90B [51] (Sect. 4.1) for FIPS 140-3 evaluations and AIS 31 [27] (Sect. 4.2) for many common criteria evaluations. RISC-V implementors may design their entropy sources to meet either one of these standards (as a different type of evidence is required for each certification). We hope that it is also possible for implementations to meet both criteria.

Alternatively, for virtual entropy sources (DRBGs), the feeding generator must meet the “256-bit security” requirements of Category 5 post-quantum cryptography (Sect. 4.3). The virtual sources are intended to be primarily provided to environments that require sharing of a physical entropy source.

4.1 FIPS 140-3 requirements (NIST SP 800-90)

The interface requirement is satisfied if 128 bits of full entropy can be obtained from each 256-bit (\(16 \times 16\)-bit) successful (ES16), but possibly non-consecutive seed output sequence using a vetted conditioning algorithm (See [51, Section 3.1.5.1.2].)

Rather than attempting to define the properties that the entropy source output must satisfy, we define that it should pass SP 800-90B evaluation and certification when conditioned cryptographically (“perfectly”) in ratio 2:1. The implication is that no specific 256-bit sequence should have a probability of larger than \(2^{-192}\) of occurring. The stochastic model or heuristic analysis must not assume that the input blocks to the conditioner are consecutive words.

Driver developers may make this conservative assumption but are not prohibited from using more than twice the number of seed bits relative to the desired resulting entropy. Even though entropy is defined in terms of 128-bit full entropy blocks, we recommend at least 256-bit security (two blocks, \(\ge 512\) bits, \(\ge 32\) words).

Rationale: SP 800-90C [8, Appendix A] states that each conditioned block of n bits is required to have \(n+64\) bits of input entropy to attain full entropy. Hence, NIST SP 800-90B [51] min-entropy assessment must guarantee at least \(128 + 64 = 192\) bits input entropy per 256-bit block [8, Sections 4.1. and 4.3.2]). Only then a hashing of \(16 \times 16 = 256\) bits from the entropy source will produce the desired 128 bits of full entropy. This follows from the specific requirements, threat model, and distinguishability proof contained in SP 800-90C. The implied min-entropy rate is \(192/256=12/16=0.75\). The implied Shannon entropy is much larger.

NIST SP 800-90C [8] further defines a set of Random Bit Generator (RBG) constructions that use an entropy source together with cryptographic components. RBG2(P) is a cryptographically secure RBG with continuous access to a physical entropy source (seed) and output generated from conditioned seeds with a DRBG. The entropy source can also be used to build RBG3 full entropy sources. Hence, this type of entropy source interface is appropriate for implementing many different types of RBGs suitable for FIPS 140-3 modules.

4.2 Common criteria requirements (BSI AIS-31)

For an alternative common criteria certification (or self-certification), implementors should target BSI AIS 31 PTG.2 (P2) [27, Section 4.3.] requirements. In this evaluation, seed bits are viewed as “internal random numbers.” The PTG.2 requirements may be mapped to security controls §T 1–3 (Sect. 5.3) and the seed interface, as shown in Table 3.

The overall security requirement is the same as with NIST sources (Sect. 4.1); that full entropy can be obtained after 2:1 cryptographic conditioning.

Table 3 Summary of AIS-31 PTG.2 requirements
Full size table

Rationale: PTG.2 modules built and certified to the AIS-31 standard can also meet the “full entropy” condition of Sect. 4.1 after 2:1 cryptographic conditioning. However, the technical validation process is significantly different. The PTG.2 source requirements work as a building block for other types of BSI generators (e.g., PTG.3 with appropriate software post-processing.)

Note how §P7 concerns Shannon entropy, not min-entropy as with NIST sources. See Sect. 4.4 for an argument why a PTG.2 source is likely to satisfy the full-entropy requirement of Sect. 4.1.

4.3 Virtual sources: security requirement

A virtual source is intended especially for guest operating systems, sandboxes, emulators, and similar use cases. A virtual source should not be considered to be a physical entropy source. However, we would like to guarantee that even such virtual environments have sufficient entropy available.

Virtualized environments should minimize security risks by using a DRBG or other secure random on the host rather than sharing the host’s hardware-backed entropy source to a guest environment. See Sect. 5.1 for a discussion about access control.

A random-distinguishing attack should require computational resources comparable or greater than those required for an exhaustive key searching on a block cipher with a 256-bit key (e.g., AES 256).

Any implementation of seed that limits the security strength shall not reduce it to less than 256 bits. If the security level is under 256 bits, then the interface must not be available.

Rationale: DRBGs can be used to feed other (virtual) DRBGs, but deterministic cryptographic processing never increases the total amount of entropy in the system. The entropy source must be able to support current and future security standards and applications. The 256-bit requirement maps to “Top Secret” classified schemes in Suite B and the newer US Government CNSA Suite [43]. This security level is equivalent to a Category 5 classical or quantum adversary [40, Section 4.A.4 Security Strength Categories].

4.4 Further notes on the three approaches

The usage of a vetted conditioner (such as SHA-2/3) in Sect. 4.1 was specified for technical reasons related to SP 800-90B itself; non-vetted conditioners may offer similar security levels.

The 128-bit output block size was selected because that is the output size of the CBC-MAC conditioner specified in [51] and also the smallest key size we expect to see in applications.

The min-entropy assessment methodology in SP 800-90B [51] has an additional safety margin in its confidence intervals, and therefore there must be consistently more than 12 bits of min-entropy per 16-bit word. In practice, we recommend the distribution to be significantly closer to uniform (16 bits).

Comparing the Entropies. We emphasize that the SP 800-90B validation process is concerned with “guessing entropy” or min-entropy \(H_\infty \), while AIS-31 is concerned with more traditional Shannon entropy \(H_1\). These two Rényi entropies are algebraically different. Min-entropy does not satisfy some of the familiar, intuitive properties of Shannon entropy—such as subadditivity.

The SP 800 90B requirement can be expressed as entropy rate bound \(H_\infty > 0.75\), and the AIS-31 requirement as \(H_1 > 0.997\). The two conditions are clearly not mutually exclusive, but the following theorem illustrates that an entropy source may have one without the other, at least when 16-bit blocks are considered in isolation. Hence, one should not assume that high Shannon entropy from AIS-31 tests guarantees that the lower min-entropy bound is reached.

Theorem 1

For a 16-bit discrete random variable X, \(\frac{1}{16}H_1(X) > 0.997\) for does not imply \(\frac{1}{16}H_\infty (X) > 0.75\) and \(\frac{1}{16}H_\infty (X) > 0.75\) does not imply \(\frac{1}{16}H_1(X) > 0.997\).

Proof

We consider two independent sample distributions \(D_1\) and \(D_2\) of a 16-bit variable \(X \in {\mathbb {Z}}\), \(0 \le X < 2^{16}\), taking on values with probability \(p_x=\Pr (X = x)\).

Claim 1. \(D_1\) has \(p_0 = 0.00650\) and \(p_i=\frac{1-p_0}{2^{16}-1}\) for \(0< i < 2^{16}\). We have \(\frac{1}{16}H_1(D_1) = 0.99703\) and \(\frac{1}{16}H_\infty (D_1) = 0.45408\).

Claim 2. \(D_2\) has \(p_i = 1/4097\) for \(0 \le i < 4097\) and \(p_i=0\) for \(4097 \le i < 2^{16}\). We have equivalent \(\frac{1}{16}H_1(D_2) = \frac{1}{16}H_\infty (D_2) = 0.75002\). \(\square \)

However, if the Shannon entropy is analyzed per bit, with information about other bits, then \(H_1 > 0.997\) implies a maximum individual guessing probability of 0.53223 per bit, or \(2^{-233}\) for a 256-bit block. Since this min-entropy is above the \(128+64\) threshold set in SP 800-90C, one can expect that a PTG.2 source satisfies the full-entropy requirements of Sect. 4.1 after cryptographic conditioning.

Still, if some specific 256-bit entropy source output sequence has an expected probability larger than \(2^{-192}\) (for any reason), then it is not a valid entropy source for this interface. The min-entropy requirement overrides much looser Shannon entropy estimates.

5 Information flows and security controls

The noise source state shall be protected from adversarial knowledge or influence to the greatest extent possible. The methods used for this shall be documented, including a description of the (conceptual) security boundary’s role in protecting the noise source from adversarial observation or influence.

-Noise Source Requirements, SP 800-90B [51].

An entropy source is a singular resource, subject to depletion and also covert channels [15]. Observation of the entropy can be the same as the observation of the noise source output, as cryptographic conditioning is mandatory only as a post-processing step. SP 800-90B and other security standards mandate protection of noise bits from observation and also influence.

Table 4 Entropy source extension access policy in relation to standard privilege levels [56]
Full size table

5.1 Access control

Typically, the seed CSR is not available to general user processes, and the raw source interface has been delegated to a vendor-specific test interface mnoise. The test interface and the main interface must not be operational at the same time.

Other than M-mode access to the entropy source is controlled via the mseccnf CSR: sseed (bit 9) for S mode and useed (bit 8) for U mode.

Table 4 summarizes the access patterns in relation to the basic RISC-V privilege levels.

The interface guarantees that access to this CSR will make seed entropy values available only once. All successful accesses will have the side effect of clearing (polling) the register. A nondestructive read attempt (such as CSRRS / CSRRC with rs1=x0 or CSRRSI / CSRRCI with zero immediate) on seed will raise an Illegal Instruction Exception.

If both S and HS mode and mseccfg are not implemented in a system, then access to the entropy source is M-mode only.

If S/HS are not implemented, or mseccfg is not available in a system, then access to the entropy source is M-Mode only.

Virtualization It is possible for a hypervisor or M-mode code to trap and feed less privileged guest virtual entropy source words (Sect. 4.3). Virtualization requires both conditioning and DRBG processing of physical entropy output. This is recommended if a single entropy source is shared between multiple different S-mode instances (multiple Kernels, not harts) or if the S-mode instance is untrusted. A virtual entropy source is significantly more resistant to depletion attacks and also lessens the risk from covert channels.

Direct U-mode an S-mode Access The useed and sseed flags allow one to draw a security boundary around a lower-level component in relation to SSP flows, which is helpful when implementing trusted enclaves or some non-Linux security policies.

It can also be useful for systems that consider an S-level kernel to be a trusted component and reserve M-mode just for system abstraction purposes. Opportunistic polling in interrupts is a natural way to gather entropy (given that the instruction is non-blocking), and its performance impact benefits from direct access in general Linux-type operating systems.

The requirement for a conditioner and DRBG implementation at a higher level introduces some latency, grows the stateful memory footprint of such a manager, and may also prove to be relatively inflexible if new types of RBGs and new security levels are required.

5.2 Security considerations

The ISA implementation and system design must try to ensure that the hardware–software interface minimizes avenues for adversarial information flow even if not explicitly forbidden in the specification.

Depletion Active polling may deny the entropy source to another simultaneously running instance. This can (for example) delay the instantiation of that instance if it requires entropy to initialize fully.

Covert Channels Direct access to a component such as the entropy source can be used to establish communication channels across security boundaries. Active polling from one instance makes the resource unavailable to another (which is polling infrequently). Such interactions can be used to establish low-bandwidth channels.

Hardware Fingerprinting An entropy source (and its noise source circuits) may have a uniquely identifiable hardware “signature.” This can be harmless or even useful in some applications (as random sources may exhibit PUF-like features) but highly undesirable in others (anonymized virtualized environments and enclaves). A DRBG masks such statistical features.

Side Channels Some of the most devastating practical attacks against real-life cryptosystems have used inconsequential-looking additional information, such as padding error messages [6] or timing information [34].

We urge implementers against creating unnecessary information flows via status or custom bits or to allow any other mechanism to disable or affect the entropy source output. All information flows and interaction mechanisms must be considered from an adversarial viewpoint; less the better.

As an example of side-channel analysis, we note that the entropy polling interface is typically not “constant time.” One needs to analyze what kind of information is revealed via the timing oracle; one way of doing it is to model seed as a rejection sampler. Such a timing oracle can reveal information about the noise source type and entropy source usage, but usually not about the random output seed words themselves. If it does, additional countermeasures are necessary.

5.3 Security controls

The primary purpose of a cryptographic entropy source is to produce secret keying material. In almost all cases, a hardware entropy source must implement appropriate security controls to guarantee unpredictability, prevent leakage, detect attacks, and deny adversarial control over the entropy output or its generation mechanism. Security controls are not mandatory for RISC-V per se (in case of virtual entropy sources) but are needed for security certification.

Many of the security controls built into the device are called “health checks.” Health checks can take the form of integrity checks, start-up tests, and on-demand tests. These tests can be implemented in hardware or firmware, typically both. Several are mandated by standards such as NIST SP 800-90B [41]. The choice of appropriate health tests depends on the certification target, system architecture, threat model, entropy source type, and other factors.

Health checks are not intended for hardware diagnostics but for detecting security issues—hence the default action should be aimed at damage control (prevent weak crypto keys from being generated). Additional “debug” mechanisms may be implemented if necessary, but then the device must be outside production use.

  • §T1: On-demand testing A sequence of simple tests is invoked via resetting, rebooting, or powering up the hardware (not an ISA signal). The implementation will simply return BIST during the initial start-up self-test period; in any case, the driver must wait for them to finish before starting cryptographic operations. Upon failure, the entropy source will enter a no-output DEAD state.

  • §T2: Continuous tests If an error is detected in continuous tests or environmental sensors, the entropy source will enter a no-output state. We define that a non-critical alarm is signaled if the entropy source returns to BIST state from live (WAIT or ES16) states. Such a BIST alarm should be latched until polled at least once. Critical failures will result in DEAD state immediately. A hardware-based continuous testing mechanism must not make statistical information externally available, and it must be zeroized periodically or upon demand via reset, power-up, or similar signal.

  • §T3: Fatal error states Since the security of most cryptographic operations depends on the entropy source, a system-wide “default deny” security policy approach is appropriate for most entropy source failures. A hardware test failure should at least result in the DEAD state and possibly reset/halt. It is a show stopper: The entropy source (or its cryptographic client application) must not be allowed to run if its secure operation cannot be guaranteed.

Rationale The testing requirement follows from the definition of an entropy source; without it, the module is simply a noise source and cannot be trusted to safely generate keying material.

These tests can complement other integrity and tamper resistance mechanisms (See Chapter 18 of [2] for examples). Some hardware random generator tests report seemingly non-adversarial environmental and manufacturing issues. However, even such “innocent” failure modes may indicate a fault attack [25] and therefore should be addressed as a system integrity failure rather than as a diagnostic issue. Security architects will understand to use permanent or hard-to-recover “security-fuse” lockdowns only if the threshold of a test is such that the probability of false-positive is negligible over the entire device lifetime.

6 Implementation strategies

As a general rule, RISC-V specifies the ISA only. We provide some additional requirements so that portable, vendor-independent middleware and kernel components can be created. The actual hardware implementation and certification are left to vendors and circuit designers; the discussion in this section is purely informational.

When considering implementation options and trade-offs, one must look at the entire information flow.

  1. 1.

    A Noise Source generates private, unpredictable signals from well-understood physical random events.

  2. 2.

    Sampling digitizes the noise signal into a raw stream of bits. This raw data is considered very sensitive.

  3. 3.

    Health tests ensure that the noise source and its environment meet its operational parameters.

  4. 4.

    Non-cryptographic conditioners remove much of the bias and correlation in input noise.

  5. 5.

    Cryptographic conditioners produce full entropy output, indistinguishable from ideal random.

  6. 6.

    DRBG takes in \(\ge 256\) bits of seed entropy as keying material and uses a cryptographic process to rapidly generate random bits on demand.

Steps 1–4 (possibly 5) are considered to be part of the entropy source (ES) and provided by the seed CSR. Adding the software-side cryptographic steps 5–6 and control logic complements it into a true random number generator (TRNG). This information flow is illustrated in Fig. 1.

Testing and Certification. While we do not require entropy source implementations to be certified designs, we do expect that they behave in a compatible manner and do not create unnecessary security risks to users. Self-evaluation and testing following appropriate security standards are usually needed to achieve this. NIST has made its SP 800-90B [51] min-entropy estimation package freely availableFootnote 2 and similar free tools are also availableFootnote 3 for AIS 31 [27].

6.1 Noise sources

The theory of random signals and electrical noise became well established in the post-World War II period [13, 24]. We will give some examples of common noise sources that can be implemented in the processor itself (using standard cells).

Ring Oscillators. The most common entropy source type in production use today is based on “free-running” ring oscillators and their timing jitter. Here, an odd number of inverters is connected into a loop from which noise source bits are sampled in relation to a reference clock [9]. The sampled bit sequence may be expected to be relatively uncorrelated (close to IID) if the sample rate is suitably low [27]. However, further processing is usually required. AMD [1], ARM [3], and IBM [29] are examples of ring oscillator TRNGs intended for high-security applications.

There are related metastability-based generator designs such as transition effect ring oscillator (TERO) [53]. The differential/feedback Intel construction [19] is slightly different but also falls into the same general metastable oscillator-based category.

The main benefits of ring oscillators are: (1) They can be implemented with standard cell libraries without external components—and even on FPGAs [52], (2) there is an established theory for their behavior [9, 17, 18] and min-entropy estimation [47], and (3) ample precedent exists for testing and certifying them at the highest security levels.

Ring oscillators also have well-known implementation pitfalls. Their output is sometimes highly dependent on temperature, which must be taken into account in testing and modeling. If the ring oscillator construction is parallelized, it is important that the number of stages and/or inverters in each chain is suitable to avoid entropy reduction due to harmonic “Huyghens synchronization” [5]. Such harmonics can also be inserted maliciously in a frequency injection attack, which can have devastating results [30]. Countermeasures are related to circuit design; environmental sensors, electrical filters, and usage of a differential oscillator may help.

Shot Noise. A category of random sources consisting of discrete events and modeled as a Poisson process is called “shot noise.” There’s a long-established precedent of certifying them; the AIS 31 document [27] itself offers reference designs based on noisy diodes. Shot noise sources are often more resistant to temperature changes than ring oscillators. Some of these generators can also be fully implemented with standard cells (The Rambus/Inside Secure generic TRNG IP [45] is described as a Shot Noise generator).

Other types of noise. It may be possible to certify more exotic noise sources and designs, although their stochastic model needs to be equally well understood, and their CPU interfaces must be secure. See Sect. 7.2 for a discussion of Quantum entropy sources.

6.2 Continuous health tests

If NIST SP 800-90B certification is required, the entropy source should implement at least the health tests defined in [51, Section 4.4]: repetition count test and adaptive proportion test, or show that the same flaws will be detected by vendor-defined tests.

Health monitoring requires some state information related to the noise source to be maintained. The tests should be designed in a way that polling some specific number of samples guarantees a state flush (no fully persistent state). We suggest flush size \(W \le 1024\) to match with the NIST SP 800-90B required tests. The state is also fully zeroized in a system reset.

Rationale The two mandatory tests can be built with minimal circuitry. Full histograms are not required, only simple counter registers: repetition count, window count, and sample count. The repetition count is reset every time the output sample value changes; if the count reaches a certain cutoff limit, a noise alarm (BIST) or failure (DEAD) is signaled. The window counter is used to save every W’th output (typically \(W \in { 512, 1024 }\).) The frequency of this reference sample in the following window is counted; cutoff values are defined in the standard. We see that the structure of the mandatory tests is such that, if well implemented, no information is carried beyond a limit of W samples.

Section 4.5 of [51] suggests additional developer-defined tests, and several more were defined in earlier versions of FIPS 140 before being “crossed out.” The choice of additional tests depends on the nature and implementation of the physical source.

The AIS 31 [27] online tests can be implemented in hardware or by driver software. For some security profiles, AIS 31 mandates that the tolerances of the tests are set in a way that the probability of an alarm is at least \(10^{-6}\) yearly under “normal usage.” There rarely is anything that can or should be done about a non-fatal alarm condition in an operator-free, autonomous system. However, AIS 31 allows the DRBG component to keep running despite a failure in its entropy source, so we suggest re-entering temporary BIST state (Sect. 5.3) to signal a non-fatal statistical error if such (non-actionable) signaling is necessary. Drivers and applications can react to this appropriately (or simply log it), but it will not directly affect the availability of the TRNG. A permanent error condition should result in DEAD state.

6.3 Non-cryptographic conditioners

As noted in Sect. 1.2.2, physical randomness sources generally require a post-processing step called conditioning to meet the desired quality requirements, which are outlined in Sect. 4. For some entropy sources, it is sufficient to reduce the output (sampling) rate; for others, it is additionally necessary to apply debiasing and other non-cryptographic conditioning methods.

The approach taken in this interface is to allow a combination of non-cryptographic and cryptographic filtering to take place. The first stage (hardware) merely needs to be able to distill the entropy comfortably above the necessary level.

  • One may take a set of bits from a noise source and XOR them together to produce a less biased (and more independent) bit. However, such an XOR may introduce “pseudorandomness” and make the output difficult to analyze.

  • The von Neumann debiaser [54] looks at consecutive pairs of bits, rejects 00 and 11, and outputs 0 or 1 for 01 and 10, respectively. It will reduce the number of bits to less than 25% of the original, but the output is provably unbiased (assuming independence).

  • Blum’s extractor [12] can be used on sources whose behavior resembles n-state Markov chains. If its assumptions hold, it also removes dependencies, creating an IID source.

  • Other linear and nonlinear correctors such as those discussed by Dichtl and Lacharme [28].

Note that the hardware may also implement a full cryptographic conditioner in the entropy source, even though the software driver still needs a cryptographic conditioner, too (Sect. 4).

Rationale The main advantage of non-cryptographic filters is in their energy efficiency, relative simplicity, and amenability to mathematical analysis. If well designed, they can be evaluated in conjunction with a stochastic model of the noise source itself. They do not generally require computational hardness assumptions.

6.4 Cryptographic conditioners

Cryptographic conditioners are always required on the software side of the seed CSR ISA boundary. They may also be implemented on the hardware side if necessary. In any case, the seed CSR output must always be compressed 2:1 (or more) before being used as keying material or considered “full entropy.”

Examples of cryptographic conditioners include the random pool of the Linux operating system, secure hash functions (SHA-2/3, SHAKE [38, 39]), and the AES-based CBC-MAC conditioner [51, Appendix F].

In some constructions, such as the Linux RNG and SHA-3/SHAKE [39]-based generators, the cryptographic conditioning and output (DRBG) generation is provided by the same component.

Rationale: For many low-power targets constructions such as Intel’s [33] and AMD’s [1] hardware AES CBC-MAC conditioner would be too complex and expensive to implement solely to serve seed. On the other hand, simpler non-cryptographic conditioners may be too wasteful on input entropy if a very high-quality random output is required—ARM TrustZone TRBG [3] outputs only 10Kbit/sec at 200 MHz. Hence, a resource-saving compromise is made between hardware and software generation that allows an implementation to use the RISC-V cryptographic ISA.

6.5 The final random: DRBGs

All random bits reaching end users and applications must come from a cryptographic DRBG. These are generally implemented by the driver component. The RISC-V AES and SHA instruction set extensions [31] should be used if available as they offer additional security features such as timing attack resistance.

Currently recommended DRBGs are defined in NIST SP 800-90A (Rev 1) [7]: |CTR_DRBG|, |Hash_DRBG|, and |HMAC_DRBG|. Certification often requires known answer tests (KATs) for the symmetric components and the DRBG as a whole. In addition to the directly certifiable SP 800-90A DRBGs, a Linux-style random pool construction based on ChaCha20 [35] can be used or an appropriate construction based on SHAKE256 [39].

These are just recommendations; programmers can adjust the usage of the CPU entropy source to meet future requirements.

7 Considerations and case studies

TRNGs are available in many mainstream CPUs and mobile devices. This is by no means an exhaustive list.

Intel Secure Key Intel’s random number interface is known as “Intel Secure Key” [33] and has been available via the RDRAND instruction since Ivy Bridge (2012). A reseeding instruction RDSEED was added for Broadwell (2014). Internally, the Intel solution is based on a self-oscillating feedback circuit [19], CBC-MAC conditioning, and the CTR_DRBG [7]—both built from AES-128 (newer versions may have AES-256).

AMD AMD’s interface is compatible with Intel’s but internally uses 16 ring oscillator chains as a noise source, CBC-MAC conditioning but a higher-security AES-256 version of CTR_DRBG. AMD additionally offers raw noise output via the TRNG_RAW register in its cryptographic coprocessor (CCP) [1].

ARM-based devices The ARMv8.5-RNG ISA extension has instructions RNDR (Random Number) and RNDRRS (Reseed Random Number) that seem to work much like RDRAND and RDSEED [4]. These instructions are new and not very widely available.

More often, ARM devices interface TRNGs via a bus (e.g., APB) instead of ISA. The TrustZone TRNG [3] is actually a non-ISA entropy source, built from ring oscillators [9] and a von Neumann debiaser [54]—without a DRBG or other cryptographic components. This makes the TRNG low-bandwidth but energy efficient.

7.1 Conditioning and DRBG in hardware

I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction. Relying solely on an implementation sealed inside a chip and which is impossible to audit is a BAD idea.

—Theodore Ts’o, author of the Linux RNG.Footnote 4

Our proposal does not prevent RISC-V implementers from creating full DRBG implementations as (custom) instructions, just like Intel and ARM does. However, we can offer some reasons why that may not be as useful as one might think.

No Black Boxes Cryptographers generally do not want to use hardware DRBGs directly as it would force them to blindly rely on hardware. This much more of an issue for a Linux-profile system than to a security microcontroller where the hardware and firmware are likely to come from the same vendor.

If the DRBG is hardwired to the entropy source and hardware is sourced from a third party, there is usually no easy way to verify that it is doing what it is supposed to be doing. As a source of secret keying material, an RNG is an obvious location for a potential cryptographic backdoor. It has a large potential for supply chain attacks such as hardware trojans [10] and other un-auditable backdoors in the style of NSA’s |Dual_EC_DRBG| [14].

However, most operating system kernels and well-designed cryptographic libraries use (and welcome) a CPU entropy source as one of the many ingredients to their “entropy soup.” Hence, the DRBGs are usually ultimately implemented in software anyway–possibly using cryptographic ISA instructions for speed. This approach eliminates a single point of vulnerability in entropy sourcing and allows a higher level of audit transparency.

Flexibility Deterministic hardware DRBGs can become technically obsolete quickly, and ISA updates are hard. This can happen due to a standards update or hardcoded design problems and limitations. Intel’s RDRAND is designed around AES-128 with forced reseeding only every 512 invocations.

There is a simple attack that demonstrates the entropy bottleneck and forward/backward secrecy problem; if two 128-bit output blocks are known, the secret key and counter can be recovered with \(2^{128}\) classical effort. This, in turn, can be expanded to the entire segment of secret blocks, revealing up to \(512 \times 128 = 65536\) bits of keying material with no additional effort. Intel’s RDRAND generator will, therefore, create a security bottleneck in applications that are specified to support “256-bit” security.

For additional entropy (in case of unavailability of RDSEED), Intel recommends polling 1024 \(\times \) 64 bits out of the RDRAND to force a reseed flush and then reducing the DRBG output back to 128 bits (a process with 99.8% redundancy) [33]. Hence, users were recommended to effectively “bypass” the large, expensive DRBG component at the cost of many thousands of cycles only a few years after its introduction.

Resource sharing High-throughput DRBG sharing can be tricky to implement, as the CrossTalk/SRBDS vulnerability shows [44]. This vulnerability causes the same random output bytes to be available simultaneously to multiple cores. The SRBDS mitigation serializes the entire DRBG operation by locking the (memory) bus for RDRAND calls and can have a serious performance impact [21]. Of course, such problems may also occur if an entropy source is shared rather than a DRBG. However, entropy source interfaces are not designed for throughput, so more conservative design choices for the sharing mechanism can be made.

Area In a small microcontroller-type RISC-V implementation, it is difficult to justify the hardware area requirement of a full-sized AES or some other cryptographic algorithm just to provide cryptographic conditioning or a DRBG output. One would prefer to use that area for cryptographic instructions that actually increase the throughput of secure communications (TLS, IPSec), or storage encryption, in addition to the DRBG component. Random number entropy is rarely a performance bottleneck in cryptographic implementations, so using a lot of transistors for RNG speed is not compatible with the quantitative approach usually associated with RISC CPU design.

Security Implementing conditioning and DRBG components in software has the same security risks as any cryptographic software. Arguably software allows more flexibility in terms of mitigations, and in some ways, the more redundant output of the entropy source with cryptographic mixing in the post-processing stage is more secure against information leakage at the interface point. Information leakage (e.g., Hamming weight via a side channel) has more direct bit-security implications if used for cryptographic keying without software hashing or other post-processing.

7.2 Quantum versus classical random

The NCSC believes that classical RNGs will continue to meet our needs for government and military applications for the foreseeable future.

-U.K. QRNG Guidance, March 2020 [36].

A Quantum Random Number Generator (QRNG) is a TRNG whose source of randomness can be unambiguously identified to be a specific quantum phenomenon such as quantum state superposition, quantum state entanglement, Heisenberg uncertainty, quantum tunneling, spontaneous emission, or radioactive decay [22].

Direct quantum entropy is theoretically the best possible kind of entropy. A typical TRNG based on electronic noise is also largely based on quantum phenomena and is equally unpredictable—the difference is that the relative amount of quantum and classical physics involved is difficult to quantify for a classical TRNG.

QRNGs are designed in a way that allows the amount of quantum-origin entropy to be modeled and estimated. This distinction is important in the security model used by QKD (quantum key distribution) security mechanisms which can be used to protect the physical layer (such as fiber optic cables) against interception by using quantum mechanical effects directly.

This security model means that many of the available QRNG devices do not use cryptographic conditioning and may fail cryptographic statistical requirements [20]. Many implementers may consider them to be entropy sources instead.

Relatively little research has gone into QRNG implementation security, but many QRNG designs are arguably more susceptible to leakage than classical generators (such as ring oscillators) as they tend to employ external components and mixed materials. As an example, amplification of a photon detector signal may be observable in power analysis, which classical noise-based sources are designed to resist.

Post-quantum cryptography (PQC). The NIST PQC public-key cryptography standards [40] do not require quantum-origin randomness, just sufficiently secure keying material. Recall that cryptography aims to protect the confidentiality and integrity of data itself and does not place any requirements on the physical communication channel (like QKD).

Classical good-quality TRNGs are perfectly suitable for generating the secret keys for PQC protocols that are hard for quantum computers to break but implementable on classical computers. What matters in cryptography is that the secret keys have enough true randomness (entropy) and that they are generated and stored securely.

Of course, one must avoid DRBGs that are based on problems that are easily solvable with quantum computers, such as factoring [50] in the case of the Blum-Blum-Shub generator [11]. Most symmetric algorithms are not affected as the best quantum attacks are still exponential to key size [16].

As an example, the original Intel RNG [33], whose output generation is based on AES-128, can be attacked using Grover’s algorithm with approximately square-root effort [23]. While even “64-bit” quantum security is extremely difficult to break, many applications specify a higher security requirement. NIST [40] defines AES-128 to be “Category 1” equivalent post-quantum security, while AES-256 is “Category 5” (highest). We avoid this possible future issue by exposing a direct access to the entropy source, which can derive its security from information-theoretic assumptions only.

8 Evolution of the design

Some of the early RISC-V CETG designs (predating “scalar cryptography” work [31, 32]) had many more states and possibly complex interaction mechanisms, which were simplified to the bare minimum that could still meet the stated requirements.

Even though the basic seed CSR interface remains the same as in an early publication [48], there have been some important changes.

Addition of AIS-31 and Virtual Sources Early versions only referenced SP 800-90B requirements (Sect. 4.1), but AIS-31 requirements (Sect. 4.2) were added after it became clear that there is still some divergence between the two sets of rules. Virtual sources were added so that emulators and virtualization platforms could be facilitated.

Full Entropy after Conditioning There has been significant changes to the language of the entropy requirements, which previously loosely discussed “8 bits per 16-bit word.” The full-entropy requirements in the SP 800-90C draft [8] forced the largest change in this (Sect. 4.1), even though 2:1 conditioning is still used.

No formal IID requirement Earlier versions of the entropy source interface mandated an IID (independent and identically distributed) source, but this was dropped as an unhelpful restriction. If the seed words have sufficient entropy so that 2:1 conditioning yields full entropy by SP 800-90C definitions, then that alone makes it independent enough. In other words, one may determine some partial information about the input entropy (e.g., distinguish it from perfect random) but never obtain most of the entropy of an undisclosed word from other words. In any case, that leaked information is not helpful in guessing anything about the conditioned output, which is “full entropy.”

ENT Scope An earlier version of this work [48] discussed a reference implementation that has since gone through a significant revision. The ESVTS and separate entropy scope (Sect. 1.2.1) is a new and welcome development, which more readily allows vendors to license approved “readymade” entropy source modules and connect them to CPU cores within their SoCs.

Optional U and S-Mode Access Another late (RISC-V architectural review) change was to reassign mentropy as seed so that it can be accessed from U and S modes (and hypervisor HS mode [56]) too—if additional access conditions in the machine security configuration register are satisfied. The RISC-V architectural review process change also made seed polling “destructive,” removed the previous pseudoinstruction pollentropy, and reordered the OPST states.

9 Conclusions

The RISC-V Cryptographic Extensions Task Group is working to introduce true random number generator (TRNG) support. The proposed CSRs, instructions, and the wider TRNG architecture are designed to allow compliance with FIPS 140-3 and related international standards such as AIS 31 at high assurance levels while being extremely lightweight to implement.

The proposal differs from other contemporary TRNG ISAs in that it is based on a polling paradigm and focuses on providing entropy source (ES) functionality only. The interface can be used to instantiate a random number generator of virtually any strength if a physical entropy source is available.

We have described the seed CSR and its basic implementation and entropy requirements. These definitions are needed so that interoperable drivers can be implemented—they set the minimum standards that can be expected from polled randomness.

We further discussed information flows, testing interfaces, monitoring, and implementation aspects in detail, diving into the rationale of various engineering decisions that are required.

We concluded with case studies that contain a brief overview of generators in current mainline ISAs, commentary on the impact of quantum threat on TRNG generation. We share the opinion of national security authorities that on-chip generators are well suited for the post-quantum cryptography era. A direct ISA interface provides a good level of implementation security, especially when compared to externally interfaced components with a more complex security boundary.