Generate random bytes #1730
Comments
|
Hi @xNado, TL;DR: it looks like something's wrong with entropy gathering. You should not need to call any PRNG initialization function. More investigation is needed.
That's for the theory. Now, indeed I observe that after each boot of QEMU, the output of It looks like |
|
It seems Fortuna needs to be fed lots of entropy bytes before the output of the first random read will change. See this discussion: https://groups.google.com/forum/#!msg/libtom/yzfarD7k2nA/-7h9zyuuHjcJ. |
|
It may be worth looking at how FreeBSD does the randomness. Their /dev/random device will block initially, until the driver believes it has enough entropy (such as loading a previous state). Then it doesn't block any more. |
|
Hi, what's the status with this bug? It's a very critical point. Without randomness the whole cryptography is pointless. Should I call the function as many times as described in the google discussion? Or will this be fixed in optee os? |
|
Hi @xNado , We have patches ready basically since this was brought up, we will submit them as a PR probably this week. Reason for delaying is that we have a disclosure process which involves talking to the stakeholders of OP-TEE also. So even though we could and want to submit fixes asap, there are some cases where we do things with the stakeholders before publish everything. But again, we will submit the PR probably this week. Thanks for reaching out and sending a reminder. |
This commit fixes a vulnerability that affects platforms built with CFG_WITH_SOFTWARE_PRNG=y. Note however that platforms built with CFG_WITH_SOFTWARE_PRNG=y *and* CFG_SECURE_TIME_SOURCE_REE=y are still vulnerable, unless they provide an implementation of plat_prng_add_jitter_entropy_norpc(). The LibTomCrypt API is not used properly in the current PRNG initialization code (tee_ltc_prng_init()). We have: prng->start(); prng->ready(); plat_prng_add_jitter_entropy_norpc(); ...and at this point, the PRNG is assumed to be ready to provide random data through rng->read(). That is broken, because there is no guarantee that the added entropy will have an immediate effect on the output of rng->read(). In fact, it usually will NOT. For instance, the default software PRNG used in OP-TEE (Fortuna) re-seeds its PRNG generator from the entropy pools only once every ten reads. So we're effectively using an un-seeded generator for the first ten calls to prng->read(). Practically it means that the same byte sequences are generated after each boot and, for the Fortuna PRNG, until the 11th call to the PRNG read function. At the Internal Core API level, this affects TEE_GenerateRandom() and TEE_GenerateKey(). The fix is simple: prng->ready() seeds the generator from the pools, so by moving plat_prng_add_jitter_entropy_norpc() before prng->ready(), we can ensure that some amount of entropy is used immediately. Fixes: OP-TEE#1730 Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
This commit fixes a vulnerability (OP-TEE-2017-0001) that affects platforms built with CFG_WITH_SOFTWARE_PRNG=y. Note however that platforms that also set CFG_SECURE_TIME_SOURCE_REE=y are still vulnerable, unless they provide an implementation of plat_prng_add_jitter_entropy_norpc(). The LibTomCrypt API is not used properly in the current PRNG initialization code (tee_ltc_prng_init()). We have: prng->start(); prng->ready(); plat_prng_add_jitter_entropy_norpc(); ...and at this point, the PRNG is assumed to be ready to provide random data through rng->read(). That is broken, because there is no guarantee that the added entropy will have an immediate effect on the output of rng->read(). In fact, it usually will NOT. For instance, the default software PRNG used in OP-TEE (Fortuna) re-seeds its PRNG generator from the entropy pools only once every ten reads. So we're effectively using an un-seeded generator for the first ten calls to prng->read(). Practically it means that the same byte sequences are generated after each boot and, for the Fortuna PRNG, until the 11th call to the PRNG read function. At the Internal Core API level, this affects TEE_GenerateRandom() and TEE_GenerateKey(). The fix is simple: prng->ready() seeds the generator from the pools, so by moving plat_prng_add_jitter_entropy_norpc() before prng->ready(), we can ensure that some amount of entropy is used immediately. Fixes: OP-TEE#1730 Link: https://op-tee.org/security-advisories Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Hey,
I want to use LibTomCrypt in my TA to generate random keys (on QEMU Optee v8). If I use the following methods I get repeatedly the same "random" bytes.
res = TEE_GenerateKey(obh, key_size, attr, attr_size)res = TEE_GenerateRandom(buf, buf_size)Did I have to initialize the PRNG by myself or is it initialized automatically when i call the functions?
Your help is much appreciated!
The text was updated successfully, but these errors were encountered: