Public-key validation in ML-KEM draft standard

[Peter Schwabe]

Dear all,

At the Oxford PQC summit we had a rather extensive discussion about the
modulus check for the public key the ML-KEM draft standard (see lines
984 ff. in [1]), which was not part of the round-3 Kyber specification.
Let's say that the input byte string encoding the polynomial is PK
(ignore the public seed rho here), then we have three options for
Encaps:

1.) pk = Decode(PK)
if(ModulusCheck(pk) == fail): abort

2.) pk = Decode(PK)
Proceed with pk and H(PK)

3.) pk = Decode(PK)
Proceed with pk and H(Encode(pk))

Option 1.) is what the draft standard does.

Option 2.) reduces coefficients of the polynomials modulo q and uses
the input byte string PK as input to the Hash. This is pretty much
what (hopefully) existing implementations do.

Option 3.) reduces mod q and uses the re-encoded reduced polynomial
as input to H. There was solid agreement that option 3.) is a bad idea.


The main argument for option 1.) is the philosophy that you don't
compute on inputs that you know to be malformed or "fishy". So, this
check would be somewhat in line with, for example, the "point-on-curve"
check during encryption in HPKE.

The main arguments for option 2.) are
* In languages that don't support returning exceptions (like C),
you'd have to fail by returning a non-zero value. As some callers
will ignore that return value, you'd also have to specify how to
fill the return buffers in that case, which makes a full
specification and possibly also implementation of option 1.) more
complex. Generally, forcing the caller to deal with non-zero
return codes also adds complexity for the caller.

* There are many ways for a bad implementation of key generation to
generate bad keys (the most obvious example is the all-zero key).
Checking just one possible way to screw up is a bit arbitrary.

In particular the first of these two arguments made us lean towards
recommending option 2.) during the discussion in Oxford.


All the best,

Peter


[1] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf

[Markku-Juhani O. Saarinen]

Peter,

Thanks for the summary. Here's an additional argument for option (2).

The "modulus check" input validation (Section 6.2 of FIPS 203 ipd) was not present in previous specifications or implementations. It is framed in terms of "abort" in case of failing check. Line 987 states that "application-appropriate steps shall be taken to abort." As in most standards, the keyword "shall" indicates a formal requirement (see definition on line 385) and, therefore, this new check is required in all compliant implementations (and should be tested in FIPS certification, etc.) So this is simultaneously rather vague (abort? what does that mean in protocol x? an error message y?) and very strict -- the implementor has to do something special in this case.

My main objection is that this requirement complicates the state machine, implementations, and security proofs of protocols that use Kyber. It also complicates testing. Without it, the Kyber Encapsulation and Decapsulation are deterministic functions from fixed-length byte strings to fixed-length byte strings (if we include the random inputs) and Kyber can be used in "garbage-in garbage-out" mode without the caller being aware if the input is valid (e.g., correctly decrypted) or not.

There is no obvious security reason for this check, and in any case, protocol designers should not assume anything from it, as it does not catch all invlaid public keys. Due to the use of hash H(ek) in the derivation of the shared secret, option (2) does not make the public key "malleable" -- modifying the public key in any way will always impact the shared secret.

Additional note: There are "type checks" (Lines 982, 1011, 1013) in both Encapsulation and Decapsulation, which check that the input byte string is of specified length (all inputs and outputs of Kyber at a specific security level have a constant length.) I support the statement that one should not proceed with the execution of the primitive if insufficient data is available -- padding is in no way applicable to these schemes.

Cheers,

- markku

[Dang, Quynh H. (Fed)]

Hi Markku-Juhani,

 

Thank you for your discussion. Please see my comment below. I am trying to understand your comment correctly.

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Markku-Juhani O. Saarinen
Sent: Wednesday, September 27, 2023 10:18 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Peter Schwabe <pe...@cryptojedi.org>
Subject: [pqc-forum] Re: Public-key validation in ML-KEM draft standard

 

Peter,

 

Thanks for the summary. Here's an additional argument for option (2).

 

The "modulus check" input validation (Section 6.2 of FIPS 203 ipd) was not present in previous specifications or implementations. It is framed in terms of "abort" in case of failing check. Line 987 states that "application-appropriate steps shall be taken to abort." As in most standards, the keyword "shall" indicates a formal requirement (see definition on line 385) and, therefore, this new check is required in all compliant implementations (and should be tested in FIPS certification, etc.) So this is simultaneously rather vague (abort? what does that mean in protocol x? an error message y?) and very strict -- the implementor has to do something special in this case.

 

My main objection is that this requirement complicates the state machine, implementations, and security proofs of protocols that use Kyber. It also complicates testing. Without it, the Kyber Encapsulation and Decapsulation are deterministic functions from fixed-length byte strings to fixed-length byte strings (if we include the random inputs) and Kyber can be used in "garbage-in garbage-out" mode without the caller being aware if the input is valid (e.g., correctly decrypted) or not.

 

There is no obvious security reason for this check, and in any case, protocol designers should not assume anything from it, as it does not catch all invlaid public keys. Due to the use of hash H(ek) in the derivation of the shared secret, option (2) does not make the public key "malleable" -- modifying the public key in any way will always impact the shared secret.

 

Additional note: There are "type checks" (Lines 982, 1011, 1013) in both Encapsulation and Decapsulation, which check that the input byte string is of specified length (all inputs and outputs of Kyber at a specific security level have a constant length.) I support the statement that one should not proceed with the execution of the primitive if insufficient data is available -- padding is in no way applicable to these schemes.

[Dang, Quynh H. (Fed)]  Are you suggesting that we should say something like “The caller shall make sure that the length of the Encap key or Decap  key is correct before calling Encap or Decap respectively.” and that should be all: no further length check and no further modulus check in Encap and Decap ?

Regards,

Quynh.

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/cadf517c-310d-425c-86c0-2abe25be5e0bn%40list.nist.gov.

[Markku-Juhani O. Saarinen]

On Wednesday, September 27, 2023 at 3:31:50 PM UTC+1 Dang, Quynh H. (Fed) wrote:

Thank you for your discussion. Please see my comment below. I am trying to understand your comment correctly.

(..)  

Additional note: There are "type checks" (Lines 982, 1011, 1013) in both Encapsulation and Decapsulation, which check that the input byte string is of specified length (all inputs and outputs of Kyber at a specific security level have a constant length.) I support the statement that one should not proceed with the execution of the primitive if insufficient data is available -- padding is in no way applicable to these schemes.

[Dang, Quynh H. (Fed)]  Are you suggesting that we should say something like “The caller shall make sure that the length of the Encap key or Decap  key is correct before calling Encap or Decap respectively.” and that should be all: no further length check and no further modulus check in Encap and Decap ?

Regards,

Quynh.

Hi Quynh,

Yes, exactly. The input validation "type check" in encapsulation [Line 982] and the "type checks" in decapsulation [Lines 1011, 1013] appear (to me) to be basically length checks. While I support Peter's argument to remove the "modulus check" [Line 984], I support the "abort" language (Section 6.2) here as there is no meaningful interpretation for Kyber ciphertexts or public keys that are not exactly the specified length. If the input variables are byte strings of the correct length, and if other prerequisites exist (e.g., the RBG is functional), Encaps and Decaps should proceed and return fixed-length byte lengths.

Recall that Kyber decapsulation never fails; implementations actually do quite a bit of extra work (Fujisaki-Okamoto transform -- Steps 7-11 of Alg. 17) to "hide" all error conditions related to invalid ciphertext. Similarly, Encaps works for all inputs of the correct length (with option 2 outlined in Peter's message), and there is no need to check the public key further.

There may be implementors who interpret some old standards about padding in key establishment functions (stranger things have happened), so it is good to explicitly include the language about length ("type") checks even though it is quite obvious to cryptographers.

Cheers.

- markku

[Dang, Quynh H. (Fed)]

Hi Markku,

 

Thank you for the clarification!

 

Hi all,

 

( My discussions do not represent any views or thoughts of any other person or group. I am seeking technical correctness, perfection/betterness (if possible) and understanding.)

 

Within the option 2, I think the modulus reduction step is not needed.

 

The current implementations from the Kyber's team and Cloudflare do not do this reduction step, but they can still produce correct output because the reduction happens later in the Encrypt and it preserves correctness. So, implementations may skip that step as long as the Encap produces the correct result at the end.

 

The issue is that new implementers might implement that step unnecessarily if we add it to the specification, and that would add cycle cost for all executions of the Encap forever.

 

The aim of the reduction step is to avoid the risk of an overflow which could lead to wrong computation results when the coefficient(s) are larger than (q - 1), outside of Zq. 

 

However, taking a closer look, it seems that the sensible and rightful concern above turns out to be not a concern.

 

First, the coefficients' size is 12 bits, so if they are larger than (q - 1), from 3329 to 4095, they are still 12 bits long. Therefore, if an implementation handles the required computations (multiplications and additions) between the coefficients in Zq correctly without having an overflow in an Encap, it should also not have an overflow with some or all coefficients being larger than 3328.

 

Secondly, our key gen requires the coefficients of the public key being in Zq. If the implementer follows our specification (requirement), there are no coefficients being out of the range, out of Zq.

 

If a key gen implementation generates a public key whose coefficients being outside of the range sometimes or all of the times, for example instead of 1, 2 the coefficients are q + 1 and q + 2 etc....(these are functionally equivalent coefficients in Zq), the reduction is not handled correctly in this implementation. And, very likely a key pair from this implementation is not a functional key pair (meaning the Decap always fails). The reason is that the resulting coefficients of the public key come from many multiplications and additions. If the reduction is not performed, it is very likely that one or more of the unreduced coefficients in the public key are not functionally correct due to an overflow since the size of the coefficients remains the same,  only 12 bits.   The Encap does not need to make sure that the result is computationally correct, not having an overflow, with a nonfunctional public key, a wrong public key.

 

Regards,

Quynh.

 

From: Markku-Juhani O. Saarinen <mjos....@gmail.com>
Sent: Wednesday, September 27, 2023 11:00 AM
To: pqc-forum <pqc-...@list.nist.gov>

[Joost Renes]

Hi Peter, Markku, Quynh, all,

 

Thank you for your comments on public-key validation of Kyber.

Below the point of view from NXP.

 

Firstly, could you please quantify what the expected saving is of removing this boundary check?

With respect to the remainder of the Encapsulation, this seems negligible.

So we do not consider the improved efficiency of Encapsulation a very strong argument against having the bound check.

 

Secondly, the wish for error-free APIs is understandable but seems unrealistic in virtually all (industrial) software environments.

For example, Encapsulation will require a call to a randomness source which shall be implemented using a prescribed function from SP 800-90* (see paragraph “Randomness generation” on Line 682 of FIPS 203 draft).

Quoting from SP 800-90A section 9 (page 26): “When the generate function returns an error, a null string is returned as the output string (see Section 9.3.1) and shall not be used as pseudorandom output.”

Are you proposing not to handle this RNG error within Encapsulation, and would there not be an issue with compliance?

Regardless of SP 800-90*, validation of RNG output is a good practice for cryptographic implementations.

Besides RNGs, many implementations will have to deal with various other types of error handling to deal with HW for SHA3, NTTs, etc. (but this is not applicable everywhere)

Can you really guarantee no loss of security whatsoever when return error codes are ignored by the caller?

 

On the other hand, input sanitation is a general good practice and especially so for cryptographic implementations that have failed due to malformed inputs time after time.

We are in favor of option 1): including the explicit step to verify the public key in Encapsulation as proposed in the current draft standard.

At the moment, we do not see that option 2 will really lead to meaningfully improved efficiency or security in practice.

 

Kind regards,

NXP PQC Team

 

 

From: 'Dang, Quynh H. (Fed)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Wednesday, September 27, 2023 6:02 PM
To: Markku-Juhani O. Saarinen <mjos....@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Cc: Peter Schwabe <pe...@cryptojedi.org>

Subject: [EXT] RE: [pqc-forum] Re: Public-key validation in ML-KEM draft standard

 

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

 

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/MW4PR09MB10059A7F90D38A6A3CC3B6131F3C2A%40MW4PR09MB10059.namprd09.prod.outlook.com.

[Markku-Juhani O. Saarinen]

Hi Joost,

- Performance was not a motivation in either direction, although Quynh did mention it as a consideration in a response.

- No one has proposed to remove checks for RNG functionality. I explicitly mentioned that RBG output should be checked.

All in all, no one has suggested that all error codes are ignored. This "error code" has not existed before.

Current implementations analyzed over the last five years do not have this error state; NIST has newly added it. Basically, the new NIST modulus check does not increase security in application protocols from what it is; it just makes their behavior "undefined."

This new error state has not been a part of security analysis when PQ migration in application protocols such as TLS has been tested thus far. The behavior of cryptography stacks that use modules that implement the check will vary depending on the vendor, as the "abort" language is ambiguous. So,  crypto stacks using, say,  NXP modules may become "distinguishable" from other implementations if you add it. That alone is a sort of security vulnerability.

Cheers,

-markku

[Dang, Quynh H. (Fed)]

Hi Joost and all,

 

Thank you for the comment/discussion.

 

( My discussions do not represent any views or thoughts of any other person or group. I am seeking technical correctness, perfection/betterness (if possible) and understanding.)

 

I heard a comment from someone which said that the 32-byte random string should be treated as an input to the function so that testing would be easier.  With this, how this seed is generated is the system matter, not matter with the Encap. The caller just passes a 32-byte array to the Encap along with a right size public key.

 

What do you think ?

 

Regards,

Quynh.

[Markku-Juhani O. Saarinen]

On Thursday, September 28, 2023 at 11:21:23 AM UTC+1 Dang, Quynh H. (Fed) wrote:

I heard a comment from someone which said that the 32-byte random string should be treated as an input to the function so that testing would be easier.  With this, how this seed is generated is the system matter, not matter with the Encap. The caller just passes a 32-byte array to the Encap along with a right size public key.

Hi Quynh,

The "m" random variable ( Algorithm 16 ML-KEM.Encaps, Line 1 ) should be viewed as key material and have the normal RBG requirements, which should also be tested. While this requires a special hook in testing -- an inconvenience for module builders -- there is a risk that someone would view "m" as a message to be encrypted (which it technically is) if it is just passed from the caller. Note that in functional testing the entire RBG is usually hooked anyway, so it's not that big of a problem for tester.

So this is basically a safety issue: Including "m" as an argument in the ML-KEM.Encaps() in FIPS 203 is "dangerous" as that may lead to APIs also allowing m to be passed from the user, with no guarantees that a proper RBG is used. KEM APIs should force the caller to do randomization. 

Forcing "message" randomization is kind of the point of KEM interfaces in relation to traditional public key encryption APIs -- that we're finally getting rid of PKE interfaces in favor of KEM interfaces in RSA too. This is also a big part of the reasoning why direct, stand-alone use of K-PKE components is not allowed in FIPS 203 (lines 868--870).

Cheers,

-markku

[Simon Hoerder]

Hi all,

don’t call it ‘m’ if that is your worry. Misleading API nomenclature is not something that should be solved by enforcing implementation choices in my opinion.

Best,

Simon

On 28 Sep 2023, at 12:51, Markku-Juhani O. Saarinen <mjos....@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/0b385015-e3c8-4df9-925a-d44223746693n%40list.nist.gov.

[Simon Hoerder]

This time to the list…

Begin forwarded message:

From: Simon Hoerder <si...@hoerder.net>
Date: 28 September 2023 at 12:53:48 CEST
To: "Dang, Quynh H. (Fed)" <quynh...@nist.gov>

Subject: Re: [EXT] RE: [pqc-forum] Re: Public-key validation in ML-KEM draft standard

Hi Quynh,

That proposal certainly has its practical advantages. I’d call it an established and successful divide-and-conquer approach. For example, a cryptographic library can focus on implementing the cryptography, have it tested and validated. The system integrator can then reuse that library and its validation in conjunction with whatever validated TRNG they have in their crypto module and take the whole thing to module validation. For hardware accelerators, it also allows for a neat separation of quite different functionalities that get combined at [crypto] module level.

Having to do a combined algorithm and TRNG validation is possible but sounds needlessly painful to me. Not least of all because on the developer side your TRNG expert and your lattice expert probably are different people. Maybe they even work for different companies or in different time zones. For the evaluation lab, I’d still expect different experts to do the certification even if the likelihood of both working for the same company in the same building is higher. 

Sure, people can misuse the input for the random string and turn it into a foot gun. But the same can be said of overly complex implementations and certification projects where everything is connected to everything without clear boundaries.

Best,

Simon

On 28 Sep 2023, at 12:21, 'Dang, Quynh H. (Fed)' via pqc-forum <pqc-...@list.nist.gov> wrote:



Hi Joost and all,

 

Thank you for the comment/discussion.

 

( My discussions do not represent any views or thoughts of any other person or group. I am seeking technical correctness, perfection/betterness (if possible) and understanding.)

 

I heard a comment from someone which said that the 32-byte random string should be treated as an input to the function so that testing would be easier.  With this, how this seed is generated is the system matter, not matter with the Encap. The caller just passes a 32-byte array to the Encap along with a right size public key.

 

What do you think ?

 

Regards,

Quynh.

 

From: Joost Renes <joost...@nxp.com>

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/MW4PR09MB1005987BED0DBB9E5BB44C6AEF3C1A%40MW4PR09MB10059.namprd09.prod.outlook.com.

[Joost Renes]

Hi Markku,

 

> [Markku]: “All in all, no one has suggested that all error codes are ignored.”

 

> [Peter]: “In languages that don't support returning exceptions (like C), you'd have to fail by returning a non-zero value. […]  Generally, forcing the caller to deal with non-zero  return codes also adds complexity for the caller.”

 

Our understanding of Peter’s original message was that the main advantage of option 2.) was that caller did *not* have to deal with return codes (or can just ignore them).

If the caller has to deal with return error codes regardless (e.g., for the RNG), which we believe to be true, then this advantage is non-existent.

How exactly the abort should be handled and specified could still be discussed of course.

 

Kind regards,

Joost

[Dang, Quynh H. (Fed)]

Hi Joost,

 

Again, thank you for the input.

 

( My discussions do not represent any views or thoughts of any other person or group. I am seeking technical correctness, perfection/betterness (if possible) and understanding.)

 

See my comment below.

 

From: Joost Renes <joost...@nxp.com>
Sent: Thursday, September 28, 2023 5:50 AM
To: Dang, Quynh H. (Fed) <quynh...@nist.gov>; Markku-Juhani O. Saarinen <mjos....@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Cc: Peter Schwabe <pe...@cryptojedi.org>
Subject: RE: [EXT] RE: [pqc-forum] Re: Public-key validation in ML-KEM draft standard

 

Hi Peter, Markku, Quynh, all,

 

Thank you for your comments on public-key validation of Kyber.

Below the point of view from NXP.

 

Firstly, could you please quantify what the expected saving is of removing this boundary check?

With respect to the remainder of the Encapsulation, this seems negligible.

[Dang, Quynh H. (Fed)] Yes, it is a very small cost. But a KEM’s encap will be run for decades. The wasted cycles would be huge collectively. And, the modulus check does not provide any security benefits as far as I can see.

 

The caller of an Encap can make sure passing only a public key with correct length to it and how the caller handles various issues can be considered as a system matter.

 

Regards,

Quynh.

[Peter Schwabe]

Joost Renes <joost...@nxp.com> wrote:
> Hi Markku,

Hi Joost, hi Markku, hi all,

> > [Markku]: “All in all, no one has suggested that all error codes are ignored.”
>
>
> > [Peter]: “In languages that don't support returning exceptions (like C), you'd have to fail by returning a non-zero value. […] Generally, forcing the caller to deal with non-zero return codes also adds complexity for the caller.”
>
>
>
> Our understanding of Peter’s original message was that the main advantage of option 2.) was that caller did *not* have to deal with return codes (or can just ignore them).
>
> If the caller has to deal with return error codes regardless (e.g., for the RNG), which we believe to be true, then this advantage is non-existent.
>
> How exactly the abort should be handled and specified could still be discussed of course.

My understanding is that of course you want to test/validate etc. your
RNG, but not as part of Encapsulation every time your querying it. So,
option 2.) would ensure that Encaps never fails.

Cheers,

Peter

> To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/MW4PR09MB10059A7F90D38A6A3CC3B6131F3C2A%40MW4PR09MB10059.namprd09.prod.outlook.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/MW4PR09MB10059A7F90D38A6A3CC3B6131F3C2A%40MW4PR09MB10059.namprd09.prod.outlook.com?utm_medium=email&utm_source=footer>.

[Kevin Chadwick]

28 Sept 2023 16:34:45 Peter Schwabe <pe...@cryptojedi.org>:

>> Are you suggesting that we should say something like “The caller shall make sure that the length of the Encap key or Decap  key is correct before calling Encap or Decap respectively.” and that should be all: no further length check and no further modulus check in Encap and Decap ?

If reference code was written in Ada not only would it be safer and more readable than likely any other language but your APIs type could enforce the exact lengths that are discussed here and you wouldn't even need to check. It is a wonderful language for cryptography.

You might still want a check with a comment like. C users will need to perform this check.

[Bas Westerbaan]

You might still want a check with a comment like. C users will need to perform this check.

To the contrary: of all languages C is one of the few where with idiomatic APIs the length cannot be checked.

Best,

 Bas

[Simon Hoerder]

Hi all,

On 28/09/2023 17:34, Peter Schwabe wrote:
> Joost Renes <joost...@nxp.com> wrote:
>> Hi Markku,
>
> Hi Joost, hi Markku, hi all,
>
>>> [Markku]: “All in all, no one has suggested that all error codes are ignored.”
>>
>>
>>> [Peter]: “In languages that don't support returning exceptions (like C), you'd have to fail by returning a non-zero value. […] Generally, forcing the caller to deal with non-zero return codes also adds complexity for the caller.”
>>
>>
>>
>> Our understanding of Peter’s original message was that the main advantage of option 2.) was that caller did *not* have to deal with return codes (or can just ignore them).
>>
>> If the caller has to deal with return error codes regardless (e.g., for the RNG), which we believe to be true, then this advantage is non-existent.
>>
>> How exactly the abort should be handled and specified could still be discussed of course.
>
> My understanding is that of course you want to test/validate etc. your
> RNG, but not as part of Encapsulation every time your querying it. So,
> option 2.) would ensure that Encaps never fails.
>
> Cheers,
>
> Peter

A TRNG typically is required to have a continuous health test running on
all bits output from the noise source. In NIST SP800-90B this is, for
example, described in Section 4 as follows:
Continuous health tests are run indefinitely on the outputs of the
noise source while the noise source is operating. Continuous tests
focus on the noise source behavior and aim to detect failures as the
noise source produces outputs. The purpose of continuous tests is to
allow the entropy source to detect many kinds of failures in its
underlying noise source. These tests are run continuously on all
digitized samples obtained from the noise source, and so tests must
have a very low probability of raising a false alarm during the
normal operation of the noise source. In many systems, a reasonable
false positive probability will make it extremely unlikely that a
properly functioning device will indicate a malfunction, even in a
very long service life. Continuous tests are resource- constrained −
this limits their ability to detect noise source failures − so they
are usually designed so that only gross failures are likely to be
detected.
[...]
Health tests on the noise source are a required component of an
entropy source. The health tests shall include both continuous and
start-up tests.
1. The continuous tests shall include either:
a. The approved continuous health tests, described in Section 4.4,
or
b. Some developer-defined tests that meet the requirements for a
substitution of those approved tests, [...]
AIS 31 from BSI has similar requirements. So all TRNG queries will fail
with a certain low probability and some kind of error signals will
exist. Often it's up to the system to consider what kind of error
response is deployed -- try again, more extensive testing, reboot or, in
the most extreme cases, end-of-life. In a desktop (or other reasonably
high level) OS, the TRNG driver may obscure all of that from the crypto
library that consumes the randomness. In embedded systems and esp. high
security devices a wide variety of solutions exists depending on device
capabilities and threat exposure. Managing those failures shouldn't be
included in crypto libraries, in my opinion, but it may be required for
a crypto library to pass failure signals on to callers via error codes,
exceptions or interrupts.

Best,
Simon