4

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?

Timmay
  • 158
  • 1
  • 2
  • 16
  • 1
    I'm sure this is a stupid question, but have you checked that the CPU doesn't have a hardware RNG built it? Many ARM9s do, some may not. Can you tell us any more about the processor on the thing? I can't see an obvious datasheet for it. – Tom Jan 13 '14 at 16:47
  • @Tom No it's not stupid at all! I wish it had a hardware RNG built in. However, all the documentation I have from the vendor has nothing about Randomness. I can contact them directly but it's highly unlikely! – Timmay Jan 14 '14 at 08:18

1 Answers1

3

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!

Paul
  • 1,337
  • 11
  • 11
  • Thanks a lot for the well thought out answer. It seems I will have to put the threshold at zero to add other entropy sources. It is true, battery strength is not a good source of entropy, but this is a POS terminal and there are not that many sources. The only thing I have so far that approximates to good entropy is the keyboard input. I think I will have to use a seed file. Thanks a lot for the advice! – Timmay Jan 14 '14 at 09:05
  • 3
    You'd think a POS terminal, which is basically there for doing secure transactions, would be equipped with cryptographically strong randomness... – Tom Jan 14 '14 at 11:31
  • 1
    @Tom I'd hope so as well, but my experience is that it's often not the case :( – Paul Jan 14 '14 at 12:35
  • 1
    @Tinmay: You should only put the threshold to zero for sources that cannot give entropy every time.. Your battery source can always provide 4 bytes (assuming an int on a 32-bit platform).. – Paul Jan 14 '14 at 12:36
  • @Tom : Alas, this one has no randomness at all! – Timmay Jan 16 '14 at 10:47
  • @Paul Please do update the article on entropy sources :0 So here is what am going to do for my previous problem. - Generate a seed file on another OS. - Once on terminal, I will read that file using `ctr_drbg_update_seed_file` Does this sound workable?? – Timmay Jan 16 '14 at 10:52
  • 1
    @Timmay Yes, that would work. At least if you ensure that the entropy collector can still provide the 48 bytes of random for the CTR-DRBG to start. – Paul Jan 16 '14 at 14:30
  • 1
    Does adding a very predictable entropy source to an RNG weaken the entropy, make it entirely useless as a randomness source, break it instantly, or does it do nothing? – Quip Yowert May 10 '15 at 05:27
  • 1
    It does nothing to it. It does not increase entropy if it's predictable, but cannot reduce it either. – Paul May 12 '15 at 13:09