NIST have a project called Entropy as a Service; the main goal seems
to be to provide adequate entropy even on IoT devices which may have
various limitations.
https://csrc.nist.gov/projects/entropy-as-a-service
I have not yet looked at all the details but -- since Linux runs on
many IoT devices and on some of them random(4) encounters difficulties
-- I wonder to what extent this might be relevant for Linux.
On Thu, Mar 24, 2022 at 02:10:26PM +0800, Sandy Harris wrote:
> NIST have a project called Entropy as a Service; the main goal seems
> to be to provide adequate entropy even on IoT devices which may have
> various limitations.
> https://csrc.nist.gov/projects/entropy-as-a-service
>
> I have not yet looked at all the details but -- since Linux runs on
> many IoT devices and on some of them random(4) encounters difficulties
> -- I wonder to what extent this might be relevant for Linux.
There is more detail about the proposal here:
https://csrc.nist.gov/Projects/Entropy-as-a-Service/Architectures
My initial reactions:
1) This is not a matter for the kernel, but for userspace to
implement, since it involves multiple HTTP (yes, really, HTTP, not
HTTPS) and NTP exchanges --- the crypto is done explicitly since
presumably the designers didn't want to assume the IOT has a comment
and bug-free(tm) implementation of HTTPS. Probably a good idea....
2) The scheme only works if you assume that there is no collusion
between the operators of the various remote servers used in the
protocol.
3) NIST recognizes this, and has the following warning:
WARNING:The resulting from Step 6 of the protocol random data shall
not be used directly for constructing cryptographic keys with it or
as a seed to a DRBG. Instead, known cryptographic mechanisms for
combining multiple random data sources shall be used to mix random
data obtained from multiple remote EaaS instances with local, with
respect to the client system and the HRT device, randomness to
create a seed for a NIST approved DRBG. Such cryptographic
mechanisms are known in the trade as entropy/randomness extraction.
It is strongly recommended at a minimum two independent EaaS
instances located in different geopolitical locales be used as
remote sources....
My conclusion is that it's not snake oil, but it's not a magic bullet,
either. TNSTAAFL.
- Ted