entropy subsystem

[nashif]

Reported by Inaky Perez-Gonzalez:

As a developer, I need a consistent way to generate crypto-grade entropy that can be used to seed pseudo-random-number-generators for crypto, secure storage and hashing.

The subsystem shall support:

• binding HW sources of entropy to the subsystem
• harvesting entropy from said sources: -- the entropy sources that can generate entropy as part of their normal operation shall be able to push entropy to the subsystem when enough is generated -- the entropy sources that can supply entropy on demand shall support being polled by the subsystem
• means for the user to query the subssystem for N bytes of entropy -- to be resolved: support source hoping? or will be adding from multiple SW and HW sources enough?
• sources -- HW sources from SoC, drivers for entropy/crypto specific modules -- SW sources: --- drivers that have soft/random timings --- IRQ handler timings --- network noise

The current subsystem implementation (drivers/random) is not sufficient as it allows only a single source of entropy to be used. More solid entropy could be achieved by adding push points, reinforced with HW generated one.

(Imported from Jira ZEP-1314)

[nashif]

by Leandro Pereira:

Took a stab at implementing this. It's currently in code review.

https://github.com/zephyrproject-rtos/zephyr/pull/742

[nashif]

by Ruud Derwig:

A security researcher signaled the lack of a good OS built-in solution for random numbers as well. He looked at several embedded OSes. A good summary of his findings was presented at CCC: https://media.ccc.de/v/33c3-7949-wheel_of_fortune Main issues with small embedded systems are the lack of good entropy sources (the main source of entropy in GP OS CSPRNGS is human interaction (and device complexity), often lacking in small, deeply embedded systems), and PRNGs that are not lightweight. I'll invite him to review and contribute - as part part of his research he developed a solution matching his criteria.

[nashif]

Related to GH-1191