Cryptographic pseudo random number generator in embedded system?

Question

I am working on the STM32L152xx that has a peripheral to perform AES128 (CBC) encryption. However, to initialize a random IV I am looking for a good scheme to create cryptographically secure random number sequence. I'm using a simple LCRG (linear congruential generator) as a place holder for now, but this is weak.

I am new to implementing encryption on an embedded platform, so I wonder what's the common practice out there to generate cryptographic PRNG? Or what is a good strategy for choosing the key and the IV?

Most of the answers on StackOverflow for cryptographic PRNG refers to 3rd party library that isn't available on this platform. However, if it's worth the try, I can attempt to port it. Links and pointers to resources would be helpful too!

I have access to the system clock and accelerometers on board. I'm running FreeRTOS. Thanks!

Answer 1

You're probably going to need to define "Cryptographically Secure" or your application a little better. If this were for a game on a mobile phone, you could probably use the accelerometer as a source of randomness. If you're trying to sign x.509 certificates, you would might consider some attached hardware that measures radioactive decay.

In all seriousness, depending on the strength of the "Randomness" that you need consider the following:

1. The current 32-bit value of a clock that ticks every nanosecond (Period of about 4 seconds - probably "Random" enough depending on how frequently you need seeds). You'll need to make sure that you don't grab this value in a deterministic way. If when you grab it is based on user input, then it's probably OK.
2. An Avalanche Noise Generator fed into a Schmitt trigger input.
3. The Exclusive OR of all of the axes of you're accelerometer (May not be good if the thing sits still all the time, unless it picks up vibrations in its normal application). If this is for a radio that gets carried around, then this is probably OK.
4. The value of a large chunk of uninitialized memory (you'll probably want to hash it because large sections of uninitialized memory can contain similar values from power-on to power-on). Also, if your device doesn't get completely powered off, then this is probably no good.
5. Some combination of one or more of the above (Exclusive OR is probably the easiest way to combine two of the above outputs)
6. Comedy option: A CCD Camera pointed at a lava lamp

Any of the above methods may need to have some sort of de-bias algorithm applied to them. The simplest one is to consider your input 2-bits at a time. If the 2 bits are equal, discard them. 0b10 becomes 1 and 0b01 becomes 0. That will ensure that you get more-or-less the same number of 1s and 0s in your final random value.

Finally, if this is for something serious you should disregard all of the above advice and NOT ROLL YOUR OWN CRYPTO. Find some API for your platform that has been vetted already and use that. Testing an algorithm for randomness is very difficult to do.

Perhaps consider the F‑2 series of the STM32 core which apparently contains a hardware RNG