How generate REAL random number using STM32 MCU?

Question

I'm working on a project with STM32F103E arm cortex-m3 MCU in keil microvision IDE.
I need to generate random numbers for some purposes, but I don't want to use pseudo-random numbers which standard c++ libraries are generating, so I need a way to generate REAL random numbers using hardware features, but I don't know how I can do it.
Any idea? (I'm a software engineer & not an electronic professional, so please describe it simple :P)

Answer 1

The asynchronous clocks approach doesn't work well; I've tried it. The problem is that the stability of the RC clocks is quite good over short periods, so they yield a fairly stable pattern (low entropy) when timed against another RC or crystal clock.

The temperature sensor approach works a little better; rather than the method described above, you can generate an n-bit random number by reading the temperature sensor N times with the ADC configured for maximum noise (maximum resolution, no averaging, minimal sampling time) and use the low bit of each reading as a random bit, shifting it into position n. This works a little better, however it too is not very random.

The best strategy I've found so far is to leverage the randomness inherent in RAM at power-up as an entropy source. Before RAM is initialized, compute a hash (CRC, SHA, whatever) of RAM when the reason for reset is POR and save that value in an area of RAM that your startup code does not clear or a register that is not cleared across resets. Use that value as the initial seed for an LFSR that serves as a PRNG. Each time you use the PRNG, update the stored seed and use it to seed the next call to the PRNG. This way, even across resets and power cycles, you get a random sequence.

Still obviously not as good as a TRNG, but the best entropy source for a PRNG solution I've found so far. If anyone finds something better, please post it!

Answer 2

There is another method I found and tested that works quite well. It can generate true random 32bit numbers, I never checked how fast it is, may take a few milliseconds per number. Here is how it goes:

• Read the noisy internal temperature at the fastest speed possible to generate the most ADC noise
• Run the values through the hardware CRC generator, available on most (all?) STM32 chips

Repeat a few times, I found 8 times gives pretty good randomness. I checked randomness by sorting the output values in ascending order and plotting them in excel, with good random numbers this generates a straight line, bad randomness or 'clumping' of certain numbers is immediately visible. Here is the the code for STM32F03:

uint32_t getTrueRandomNumber(void) {

ADC_InitTypeDef ADC_InitStructure;

//enable ADC1 clock
RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1, ENABLE);

// Initialize ADC 14MHz RC
RCC_ADCCLKConfig(RCC_ADCCLK_HSI14);
RCC_HSI14Cmd(ENABLE);
while (!RCC_GetFlagStatus(RCC_FLAG_HSI14RDY))
    ;

ADC_DeInit(ADC1);
ADC_InitStructure.ADC_ContinuousConvMode = DISABLE;
ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right;
ADC_InitStructure.ADC_Resolution = ADC_Resolution_12b;
ADC_InitStructure.ADC_ScanDirection = ADC_ScanDirection_Backward;
ADC_InitStructure.ADC_ExternalTrigConvEdge = ADC_ExternalTrigConvEdge_None;
ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_T1_TRGO; //default
ADC_Init(ADC1, &ADC_InitStructure);

//enable internal channel
ADC_TempSensorCmd(ENABLE);

// Enable ADCperipheral
ADC_Cmd(ADC1, ENABLE);
while (ADC_GetFlagStatus(ADC1, ADC_FLAG_ADEN) == RESET)
    ;

ADC1->CHSELR = 0; //no channel selected
//Convert the ADC1 temperature sensor, user shortest sample time to generate most noise
ADC_ChannelConfig(ADC1, ADC_Channel_TempSensor, ADC_SampleTime_1_5Cycles);

// Enable CRC clock
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_CRC, ENABLE);

uint8_t i;
for (i = 0; i < 8; i++) {
    //Start ADC1 Software Conversion
    ADC_StartOfConversion(ADC1);
    //wait for conversion complete
    while (!ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC)) {
    }

    CRC_CalcCRC(ADC_GetConversionValue(ADC1));
    //clear EOC flag
    ADC_ClearFlag(ADC1, ADC_FLAG_EOC);
}

//disable ADC1 to save power
ADC_Cmd(ADC1, DISABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_ADC1, DISABLE);

return CRC_CalcCRC(0xBADA55E5);

}

Answer 3

This is an old question I just ran across, but I want to answer because I don't find the other answers satisfying.

"I need random numbers for RSA key generation."

This means that a PRNG routine (too often erroneously called RNG, a pet peeve of mine) is UNACCEPTABLE and will not provide the security desired.

An external true RNG is acceptable, but the most elegant answer is to change over to an STM32F2xx or STM32F4xx microcontroller which DOES have a built-in TRUE random number generator, meant precisely for applications such as this. For development I suppose you could use thr F1 and any PRNG, but the temptation there would be "it works, let's ship it" before using a true RNG, shipping a faulty product when the RIGHT component (certainly the ST F4, and I think also the F2 chips have been around since before this question was asked) is available.

This answer may be unacceptable for non-technical reasons (the chip was already specified, the OP had no input to the features needed), but whoever chose the chip should have picked it based on what on-chip peripherals and features needed for the application.

Answer 4

As pointed out, the chip does not have a hardware RNG.

But you can roll your own. The usual approach is to measure jitter between INDEPENDENT clocks. Independent means that the two clocks are backed by different christals or RC-oscillators and not derived from the same.

I would use:

• SysTick timer / counter derived from system clock (MHz range)
• One of the kHz-range RC oscillators

Set up a counter on the kHz-range RC oscillator to give you an interrupt several times a second. In the interrupt handler you read the current value of the SysTick counter. Whether or not SysTick is used for other purposes (scheduling), the lower 5 or so bits are by all means unpredictable.

For getting random numbers out of this, use a normal pseudo RNG. Use the entropy gathered above to unpredictably mutate the internal state of the pseudo RNG. For key generation, don't read all the bits at once but allow for a couple of mutations to happen.

Attacks against this are obvious: If the attacker can measure or control the kHz-range RC oscillator up to MHz precision, the randomness goes away. If you are worried about that, use a smart card or other security co-processor.

Answer 5

F1 series does not seem to have RNG (hardware random number generator), so your only options are to use pseudo-randoms or ask external input (some consider e.g. human hand movement random). You often get better pseudo-randoms using some crypto library instead of standard C++ libraries.