Are there some problems to use pseudo-random number generator in Smart Card?

Question

A Smart Card is a kind of secure device, with limited storage capacity and computational resource.

If we use a Pseudo-Random Number Generator to generate random numbers in a Smart Card, then is there any problem?

Answer 1

All modern microprocessor Smart Card ICs contain a physical True RNG, generally followed by conditioning using a hardware de-biaser (such as Van Neumann's) or/and deterministic Pseudo-RNG of some kind that make the TRNG output more indistinguishable from random. Independently, a Smart Card could contain a (Cryptographically Secure) Pseudo-RNG. The later is what the question as worded is about, but I'll cover both.

Yes there are possible problems with these RNGs - and techniques to deal with them.

Defective RNGs happen. In a well-documented recent example, the TRNG used inside a Smart Card to generate its RSA public/private key pair was bad on a fraction of the production, making the RSA modulus factorisable with specialized techniques. This class of failure is a bad design or build of the physical randomness source. Here it was most likely accidental, but an adversary could try to induce similar fault (e.g. by varying the temperature of the IC, its power supply..) e.g. so that a random number generated as challenge by a Smart Card actually repeats with much higher probability than normal.

In order to guard against such failure in TRNGs, the reasonable thing to do is to include tests of the TRNG source at least before conditioning, and use well-thought post conditioning, perhaps including Cryptographically Secure for some usages. This is codified in the AIS31 scheme for common-criteria security evaluation of TRNG (index in German, linking to documents in English; see also how French authorities have been using AIS31 method, including some reservation in section 5).

Sometime, the state of a PRNG is held in non-volatile memory (if it was not, when we power-off the Smart Card, the state would be lost and, absent special precaution, the PRNG's output would be the same each time we power-up the Smart Card, which is a devastating issue). The adversary would like to recover that state, or alter it to a known state (e.g. by removing power while this state is being changed). Well-designed Smart Card hardware and software have layered protections against such attacks on their non-volatile memory, making memory examination extremely difficult, preventing data loss using temporary duplicates and flags, and using techniques for detection (perhaps correction) of errors.

Another issue for implementation of a PRNG in a Smart Card is side channel and fault injection attacks (slides), which try to guess the PRNG state while it normally changes, or alter how it changes (the aforementioned power removal is a fault injection). Again, Smart Cards have an arsenal of countermeasures against these.

---

Comments suggest comparing use cases of PRNG vs TRNG in a Smart Card.

Smart Cards need randomness, and a lot of it, as part of protection against side-channel attacks. That's starting right at power-up, which can be performed an unlimited number of times (I have seen contactless Smart Card readers doing a hundred power cycles per second). A pure PRNG just can't work: it is deterministic, and will either produce the same output on two card power-up, or require update of a non-volatile memory, which is slow, easily detectable by SPA, and doable only a limited number of times in the operational life of the device. Also, this state must be initialized at some point of the life of the Smart Card, with a random secret, an operational annoyance.

That's why all Smart Cards ICs provide at least one hardware TRNG, at least for their internal use. The only hardware PRNG that I ever met on these ICs was used as post-conditioning of a TRNG. This (conditioned) TRNG provides excellent randomness, of near-crytographic quality, in usably ample quantity, easily and quickly accessible to the low-level system programmer (after a check that the TRNG is actually working, which is a source of serious complications). It is common (and the recommendation of many competent persons beyond French authorities in the aforementioned section 5) to use this as seed to a CSPRNG implemented in software (often using hardware accelerators for a block cipher) for something requiring cryptographic characteristics.