i-RISCV Hardware Entropy Sources

The i-RISCV provides a complete entropy source along with all tools necessary to analyze it to verify the compliance with the stochastic model.

Configuration FUSES

The RTL implements a FUSE controller which, however is not backed by OTP-FUSES, but with memory that is can be written to by software in RISC-V M privilege mode where the software can set a lock which makes the configuration values read-only until next reset.

The SBI code contains placeholders offering example code showing how set the FUSES and the final lock.

The FUSE allows the following individual setting for each noise source:

  • health test cutoff values individually for each health test

  • number of bits to be collected from the noise source for one complete seeding operation

Therefore, each noise source can be configured individually and independent of all other noise sources.

Noise Sources

The i-RISCV implements two different types of noise sources:

  • 4 ring oscillators based on the Elementary RO TRNG (ERO) with the Baudet et al. phase-noise model, Fischer-Lubicz embedded jitter monitor, and OpenTRNG reference RTL

  • 2 meta-stable flip-flops

Health Tests

Each instance of the noise source, i.e. each individual ring oscillator and meta-stable flip-flop, has its independent set of health tests which independently monitor the quality of the data.

If any health test flags an alarm, the noise source is deactivated independently of the others. The health status register allows software to reset the noise source to become active again. The noise source will be automatically reactivated upon reset.

Stochastic Model

A separate stochastic model for the ring oscillators and the meta-stable flip-flops is used as a basis to determine the entropy rate.

Data Size

Each noise source has its own configured number of bits to be mandatory collected for one seeding operation.

The goal with this individual configuration is to allow a post-tapeout characterization of the noise sources along with its entropy rate. Now, the entropy rate can be set to deliver the amount of entropy used as a baseline specified in the seeding strategy.

Entropy Source

The integration of noise sources is intended to be compliant with SP800-90C as well as AIS 20/31 v3.0. This section explains the integration of the noise sources to form the entropy source used to seed the XDRBG-256.

General Seeding Strategy

Before discussing the Synchronous or asynchronous seeding strategy, the general approach to seeding must be discussed as it applies in general. The XDRBG-256 is seeded with the following general considerations which apply always:

  • The XDRBG-256 after reset receives a trigger to automatically perform a seeding operation. That seeding operation must be completed before the XDRBG generates any data. This means that this seeding operation is synchronous in nature.

  • The XDRBG has two trigger points whose thresholds can be configured with the configuration FUSES.

    • Reseed trigger: When a threshold of generated bits is reached without reseeding (default is 2^16 bits), the XDRBG triggers the reseed with one of the possible seeding strategy. Yet, the XDRBG is allowed to continue to generate random bits.

    • Drop dead trigger: When a threshold of generated bits is reached without reseeding (default is 2^17), the XDRBG refuses to generate any more random bits. It synchronously waits for the seeding operation that is triggered by the reseed trigger to complete. If that seeding operation fails (e.g. a noise source health error)

    It is permissible that both trigger points are set to the same value which implies that any reseed trigger is always synchronous and required to be successful (i.e. at least one noise source must deliver data without a health alarm pending).

RBG2(P) And DRG.4/PTG.2

The XDRBG offers the ES_DRNG_RAND interface which generates data compliant to the SP800-90C RBG2(P) and AIS 20/31 v3.0 DRG.4 + PTG.2 construction.

The general construction of the seeding process can be configured at synthesis time and implements one of the following strategies further discussed in the subsequent sections

  • Synchronous seeding - albeit inferior with its performance compared to the asynchronous operation, it only uses a separate 512 bit transfer buffer and thus has less gate counts compared to the asynchronous approach.

  • Asynchronous seeding - this approach is significantly faster as entropy collection proceeds in parallel with random bit generation by the XDRBG, it requires a separate SHA3-512 instance that collects the bits from the noise sources.

flowchart LR
    RO["4 ring oscillators (health-tested)"] --> SBUF
    FF["2 metastable flip-flops (health-tested)"] --> SBUF
    RO --> AC
    FF --> AC
    subgraph SYN ["Synchronous seeding (caller stalls until seeded)"]
        direction LR
        SBUF["512-bit seed buffer"] -->|multi-staged insert| XDRBG
    end
    subgraph ASY ["Asynchronous seeding (parallel to generation)"]
        direction LR
        AC["SHA3-512 conditioning function"] -->|atomic 512-bit digest insert| XDRBG
    end
    XDRBG["XDRBG-256 (SHAKE-256 core)"] --> OUT["Random bits, max 512 per request"]

Synchronous Seeding Stratey

For the synchronous seeding strategy, the XDRBG will stall the caller until the following seeding process has successfully completed.

For the seeding operation, a 512 bit wide seed buffer is used to hold the data of the following operations.

  1. Startup all noise sources whose health test has not failed

  2. Obtain individual bits from each active noise source and concatenate them in the buffer. Due to the different numbers of bits generated by the noise sources, it is possible that at the beginning, output data from all noise sources are concatenated, later from one less down to obtaining data from the noise source with the longest data bit generation threshold.

  3. When the 512 bit seed buffer is entirely saturated, insert the buffer into the XDRBG seeding interface. That seeding interface allows a multi-staged seed process which implies that, for example, inserting 2 512 bit buffers into the XDRBG is the identical operation as if the 2 buffers are first concatenated and then inserted into the XDRBG. With this consideration, irrespective of how many instances of the seed buffer, the amount of data is mathematically treated as one long seed buffer. Once the seed buffer is inserted go back to step 2 to collect more data.

  4. The steps 2 and 3 are performed until all noise sources delivered their configured data. At that time the potentially partially filled seed buffer is inserted again into the XDRBG seed interface, but marking the seeding operation as complete.

  5. The XDRBG generates the requested number of random bits and returns them to the caller.

A seeding failure, i.e. when no noise source delivered the required amount of data returns an error to the caller.

Asynchronous Seeding Strategy

For the asynchronous seeding strategy, the XDRBG process the seeding operation independently of the XDRBG generate operation. That implies that stall the caller is provided with random bits from the XDRBG while the collection of entropy is ongoing.

For the seeding operation, a 512 bit wide seed buffer is used to hold the data collected by the noise sources.

To ensure that the entire set of data from the noise source is inserted into the XDRBG in an atomic operation and having a runtime-configurable amount of data to be collected from the noise source, a SHA3-512 conditioning function is employed to collect an arbitrary amount of data from the noise sources, compress them with the message digest and insert the 512 bit message digest into the XDRBG in an atomic operation. Thus, the following steps are implemented:

  1. The XDRBG receives the (re)seeding trigger, it triggers the following steps while servicing subsequent caller requests. Starting with the next step, only the seeding process is outlined that now runs in parallel to the XDRBG generate operation.

  2. Startup all noise sources whose health test has not failed

  3. Obtain individual bits from each active noise source and concatenate them in the buffer. Due to the different numbers of bits generated by the noise sources, it is possible that at the beginning, output data from all noise sources are concatenated, later from one less down to obtaining data from the noise source with the longest data bit generation threshold.

  4. When the 512 bit seed buffer is entirely saturated, insert the buffer into the conditioning function with a conceptual hash update operation. I.e. all collected seed buffers are mathematically concatenated for generating the message digest.

  5. The steps 3 and 4 are performed until all noise sources delivered their configured data. At that time the potentially partially filled seed buffer is inserted again into the conditioning function followed by generating the message digest.

  6. The message digest is now inserted into the XDRBG seeding interface in an atomic operation.

Note, the asynchronous seeding process also ensures that there is hardly any user-visible contention for the noise sources when the XD

RBG3(RS) And PTG.3

In addition, the XDRBG also offers the ES_DRNG_SEED interface. When requesting data from that interface, the XDRBG changes its behavior to implement an SP800-90C RBG3(RS) and AIS 20/31 v3.0 PTG.3 construction.

flowchart LR
    RO["4 ring oscillators (health-tested)"] --> BUF
    FF["2 metastable flip-flops (health-tested)"] --> BUF
    BUF["512-bit seed buffer"] -->|multi-staged insert when full| XDRBG["XDRBG-256 (SHAKE-256 core)"]
    XDRBG --> OUT["Random bits, max 256 per request"]
    OUT -.->|reseed trigger| BUF

After generating at most 256 bits of random data, a seeding operation is performed. For the seeding operation, a 512 bit wide seed buffer is used to hold the data of the following operations.

  1. Startup all noise sources whose health test has not failed

  2. Obtain individual bits from each active noise source and concatenate them in the buffer. Due to the different numbers of bits generated by the noise sources, it is possible that at the beginning, output data from all noise sources are concatenated, later from one less down to obtaining data from the noise source with the longest data bit generation threshold.

  3. When the 512 bit seed buffer is entirely saturated, insert the buffer into the XDRBG seeding interface. That seeding interface allows a multi-staged seed process which implies that, for example, inserting 2 512 bit buffers into the XDRBG is the identical operation as if the 2 buffers are first concatenated and then inserted into the XDRBG. With this consideration, irrespective of how many instances of the seed buffer, the amount of data is mathematically treated as one long seed buffer. Once the seed buffer is inserted go back to step 2 to collect more data.

  4. The steps 2 and 3 are performed until all noise sources delivered their configured data. At that time the potentially partially filled seed buffer is inserted again into the XDRBG seed interface, but marking the seeding operation as complete.

  5. The XDRBG generates the requested number of random bits and returns them to the caller.

Note: Access to the noise sources is serialized such that a complete seeding operation is completed by a separate seeding operation can take place.