4
$\begingroup$

I'm working on a security application for RF modules aimed to protect a communication between an autarkic sensor and a line-powered receiver against MITM (man-in-the-middle attacks). I decided to use a communication approach based on a unilateral authentication using a 32-bit random as Nonce with time limited validation. I'm using for that a specific development tool, a specific library written in C and a compiler(C51 of Keil microvision for those who heard about it).

This specific library is offering me the possibility to generate a 16-bit random number reading the noise of an ADC. I suppose it is a true random. So I thought of calling this function twice and concatenating the outputs to produce a 32-bit random but I'm not quite sure if it is a secure way to process a random number. So I'm asking you guys:

  • What is the entropy in the resulting value? (I read an Intel post saying that it is 17 bits of entropy in my case but I'm wondering if it's correct and I heard others saying that it is always 32 bits of entropy.)

  • How to evaluate the distribution of the resulting values over the whole range of 32 bit values [0...2^32]?

  • By calling my function twice to generate the 16-bit random values, the noise of the ADC will be read twice but considering that the process of generating these numbers is based on microscopic phenomenon I suppose it is unlikely to have two equal values such as 0x12341234 or 0xAABBAABB or whatever. It means maybe that these numbers are less likely to come than the others. Correct?

  • And last but not least, does using a cryptographic mixing (quadratic residues maybe?) after concatenating the two improve the level of security (entropy) of the resulting value or not?

$\endgroup$
8
$\begingroup$

The Intel post which I think you mean was discussed in this question and as I wrote there, the limitation only applies in the case of trying to combine PRNG outputs into values larger than the seed entropy (two 256-bit values in their case). Also mentioned there: cryptographic mixing does not increase the entropy you have, so if concatenation is insecure, just mixing is as well.

So, whether you can concatenate two 16-bit values depends on how the library/hardware works:

  • If you are getting raw noise readings it is unlikely it has 16 bits of entropy per value. You would need to collect many and mix them into a single value if you wanted truly random values. And you would need to find out what sort of correlations the data has to determine the entropy rate.
  • More likely, there is already some mixing/whitening going on that tries to assure full entropy for the output values. If that is the case, you can combine them just fine.
  • If the library uses a PRNG to generate more output values than the input entropy from the hardware you again cannot combine two values and retain full entropy.
$\endgroup$
  • $\begingroup$ thanks for the response. So you mean I'm not concerned by the intel post considering that I'm using a Hardware random number generator. Could you please explain to me what raw noise readings are ? $\endgroup$ – M.Fox Sep 17 '15 at 9:02
  • 1
    $\begingroup$ @M.Fox, likely so, but you would need to verify what the library is actually doing to be sure. By raw readings I meant the case where the library gives you numbers from the hardware where no randomness extraction or other conditioning has been performed. Those could have the kind of biases you mention in the question. $\endgroup$ – otus Sep 17 '15 at 9:06
  • $\begingroup$ thank you :) I'll see the definition of my library function to figure it out.So the entropy of a random number from a hardware random number generator depends on how my function is implemented. It's not because it is a 16-bit random that it has effectively 16 bits of entropy no? $\endgroup$ – M.Fox Sep 17 '15 at 9:46
  • $\begingroup$ @M.Fox, if each number has 16 bits of entropy, then two of them have 32. So if the library guarantees this you are fine. However, 16 is in general just an upper bound. $\endgroup$ – otus Sep 17 '15 at 9:50
1
$\begingroup$

Unrelated to your question premise, but highly related to the security of the overall scheme is that you may be opening yourself up to a side channel attack. Your supposition about the randomness may hold true as long as the hardware is secure, but if someone gains access to the device, they may be able to make your numbers less than random. This may range from easy (applying a signal to an external pin or via inductance or interference) to difficult (disassembling and replacing or removing components without damage or detection), but it's possible.

The specifics of this depend heavily on the hardware you're using, so I suggest researching the implementation of this RNG on all supported devices and not leaving it to chance.

$\endgroup$
  • $\begingroup$ Hi Patrick M :) thank you for the response.Not being an expert in hacking I don't know what to do against that? In my case I knew that a RF module is vulnerable to MITM because the attacker receives the communication (broadcast) ,blocks the targeted receiver preventing it from getting the telegram (by overwhelming it with telegrams) and relays it to a later moment.How to prevent that? I have no idea ...because even if I define an authentication with time limited validation and an nonce the attacker might not be able to relay valid commands but he might prevent my module from working correctly $\endgroup$ – M.Fox Sep 18 '15 at 7:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.