Would entropy that comes only from Trezor be enough for standalone device?

[Hannsek]

Investigate, whether entropy from STM is enough to be the only entropy needed for seed generation on standalone Trezor.

[prusnak]

I did STM RNG tests back in 2013 when we were still deciding which chip to use.

See the repo for the firmware and the results: https://github.com/trezor/rng-test

[prusnak]

Related issue #23: We can still require or at least encourage diceware and/or cointoss input when initializing as a standalone device (without host that can provide entropy, e.g. a powerbank).

[Hannsek]

Cannot the entropy be generated even from powerbank? E.g. from electric current noise.

[matejcik]

powerbanks are, afaik, the least noisy power sources that you can get without actively looking for a noise-less source

[Hannsek]

What about some internal component?

[mcudev]

I'd say, to be safe, no, it's not enough. It could be ok, but who knows. I did some work on this in 2017 too when we were getting the T2 setup. I remember running the rng-tests and them coming out ok. But, they never gave me a warm fuzzy feeling. The RM0090 section 24.3.1 stuff still really bugs me too [4]. We don't know if any particular unit is malfunctioning, biased, if any bias changes, or if any bias changes based on previous outputs. The mix with other entropy always seemed necessary to me. For my own stuff, I mix bits from multiple sources of entropy -- multiple Trezors / dev kit Trezors, dice, laptops, etc... I get at least 256 bits (usually more) from the various sources, then mix them with SHA-256 and assume that the strength of the extracted entropy is at least 128 bits based on [1][2][3].

[1] Section 6.4.2.2 https://csrc.nist.gov/csrc/media/publications/sp/800-90b/draft/documents/draft-sp800-90b.pdf [2] https://crypto.stackexchange.com/a/75706 [3] https://crypto.stackexchange.com/a/58168 [4] https://github.com/trezor/trezor-firmware/blob/master/core/embed/trezorhal/rng.c#L42-L48

[matejcik]

We don't care about bias if we end up with enough bits of actual entropy (taking into account that 1 bit coming out of a biased source might have less than 1 bit of entropy). The SHA256 at the end will take care of uniformizing the entropy across its output.

ISTM that if we start out assuming a huge bias, say, 1/20 likelihood of a 0, giving us ~0.29 bits of entropy per bit of output (by formula -(p*log2(p) + (1-p)*log2(1-p)) ... then we can compensate by consuming ~900 bits from the TRNG to gain ~260 bits of entropy and, after hashing, a solid 128-bit secret.

A complete malfunction would be a problem, but that's what the RM0090 is for.

[mcudev]

We don't care about bias if we end up with enough bits of actual entropy

Agree, BUT, if a particular TRNG is biased, we never know by how much. Plus, we can't debias it like can be done with, for example, coin tosses, because we don't know if any bias that is present changes based on previous outputs. For example, with a coin, you know it's a dumb alloy of metal that is not changing its bias after each trial (assuming you're not deforming the coin during the trial -- for argument's sake, assume you gracefully catch it in the air). That's why the von Neumann process [1] works. That's very different than the TRNG -- that could change its bias after each trial. It's a black box, and we can't assume the TRNG peripheral has a static bias. How much entropy can you say that you can rely upon getting from such a device?

The FIPS RM0090 stuff always seemed like ineffective hand waving to me. For example, the device could malfunction and continually flip flop between returning 0 and returning 1. That will pass the the FIPS check, yet still be entirely predictable. At the same time, the FIPS check does introduce a bias because it states what the output can not be based on a previous trial. That has annoyed me since I first read about it.

[1] https://en.wikipedia.org/wiki/Fair_coin#Fair_results_from_a_biased_coin

[matejcik]

that could change its bias after each trial.

But we don't care about that either, for as long as the (dynamic) bias is under some reasonable upper bound. One bit per rng_read seems like an overly cautious assumption, so we can go with that. And we can add a basic randomness check over the generated sequence just in case something is Very Wrong(tm) -- flip-flopping between two possible states is a good example but can something like that actually happen?

Generally, I'd be curious about how a failure mode would actually work, that (a) passes the RM0090, (b) passes a randomness check, and (c) still doesn't provide enough entropy. Unless the TRNG is actively malicious, that is.

(fwiw, if there could be something that wrong with the TRNG, then all current devices are potentially vulnerable because you can brute-force their seed based only on the external entropy, which is accessible to malware)

[mcudev]

Generally, I'd be curious about how a failure mode would actually work, that (a) passes the RM0090, (b) passes a randomness check, and (c) still doesn't provide enough entropy. Unless the TRNG is actively malicious, that is.

I believe that the example malfunctioning, flip-flopping between 0 and 1, device would meet these conditions. In essence, that's just a perfect dynamic bias flip after each trial. It meets (a). It would likely pass (b) because the ratio of 0's to 1's would be 1/2. Seems like that would pass a basic statistical distribution check. It meets (c) as it is predictable. If that doesn't satisfy you, then maybe a seed that gets rotated N bits on each read would. It would be a lazy/stupid implementation, but not necessarily malicious. There could be other failure modes that don't return the same value twice in a row, don't weight 0's vs 1's "too much", and are predictable. The docs say that the device is defined to sample analog noise. Altering the environment to influence that circuit to 0 or 1 is not my specialty, but maybe some creative electronics person knows how to influence such a circuit. I would not be surprised if some creative person pops up and says he can make the TRNG emit predictable sequences while running the device next to a motor, next to a 5G phone radio, by magnets, while altering the chip temperature (like carrying it inside from the cold and using it before it warms up), or some other seemingly innocuous thing that affects the analog noise sampler that the peripheral supposedly uses. EDIT: Separately, it would be interesting to get some research into how susceptible the TRNG is to being put into a state of degraded performance. By assuming external entropy would be mixed in, this was a reduced concern. If it were possible to do that by targeting energy to a specific area of the chip, it would be interesting to know.

But we don't care about that either, for as long as the (dynamic) bias is under some reasonable upper bound.

How can we continually determine that it is?

flip-flopping between two possible states is a good example but can something like that actually happen?

I see no reason why it couldn't happen. I've thought about this before when working with my lower cost kits, like [1]. I've sourced dev boards from various sources, and even if you don't assume that they are implemented maliciously, I have to figure that some of them are lower quality, and maybe even contain counterfeit parts (marked and sold as genuine). Were corners cut? Are there differences between batches? There are lots of ways that the TRNG may not be as nice as dreamed/advertised/hoped. From RM0090 24.1, "The RNG passed the FIPS PUB 140-2 (2001 October 10) tests with a success ratio of 99%." It's difficult to know what that 1% failure means and what conditions affect it. For the failure modes in crypto that poor TRNG samples lead to, I think it's hard to be satisfied with relying on this peripheral without mixing in data from other entropy sources.

[1] https://mcudev.github.io/trezor-one-low-cost-dev-kit/index.html

[prusnak]

We can get extra entropy when we tell a user to move their finger randomly while touching the screen for 5-10 seconds. Then we can hash all of the input events and use the result as extra entropy.