Question

I am tasked with making a random number generator for an embedded system. As of now, the entropy sources am using are keypad input, and other variables such as signal strength and battery strength.

I have been using PolarSSL which has an amazing portable SSL Library for embedded systems. However, save for the documentation, there is very little on the internets about it!

I think am not adding the entropy sources to my entropy accumulator the right way. This is causing trouble with the CTR-DRBG module which returns an error on Init. (Source Error -52) Since the RNG is for an embedded system, there is no initial entropy from the system hence the error. (LINK) I get no errors when I try out the same RNG on other standard OS's like Windows. Here is some of the code pertinent to it.

    // Global Variables.
ctr_drbg_context ctx;
entropy_context etx;

// Inside Main
entropy_init( &etx );
// Add entropy sources

// Initializing CTR_DRBG
printf("Before ctrdrbg: %d", err);
err = ctr_drbg_init( &ctx, entropy_func, &etx,  (const unsigned char *) "RANDOM_GEN", 10 );
if( err != 0 )
{
   printf("Failed in ctr_drbg init!: %d", err);
} 

Output: Error on Ctr_drbg init: -52

I have pored over this for about a week now with no headway. Almost giving up!! Anybody out there willing to help?

Was it helpful?

Solution

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!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top