First the factual answer:
The main reason it works on Windows is that it can use multiple OS specific entropy sources that generate 'enough' random.
The amount of entropy requested by CTR-DRBG to is 48 bytes (based on the default config).
For the entropy pool to be able to provide those 48 bytes, it will do a maximum of 256 polls (ENTROPY_MAX_LOOP
) to each entropy source and put that all in the accumulater. It expects all sources to deliver their threshold value at the least! If one does not, because it does not return more data on consecutive calls, it will fail the way it does now (POLARSSL_ERR_CTR_DRBG_ENTROPY_SOURCE_FAILED).
So you will need to provide 'better' entropy sources or define the threshold to a more appropriate value for the specific source (for some sources this can be 0 if the source cannot be expected to always deliver entropy data).
Then the security answer:
You need real entropy for the entropy pool to be useful. The battery meter is not a really secure one (as it is rather predictable (always 100 if on power) and often in a predictable range. Using keyboard input can be valuable if done right. But you'll need more.. The best way to 'kickstart' a system that does not provide a hardware RNG in its chipset is to use a seed file that is generated on a more secure system and read that and update it at startup and shutdown. You can use this seed file as an entropy source ir feed it directly in the ctr_drbg. In your case I would expect you to have only very low threshold sources (sometimes 0) and get the main entropy from a seed file.
Edit: I will enhance our Knowledge Base article on adding entropy sources to better cover this situation!