Cryptographic pseudo random number generator in embedded system?

Question

I am working on an STM32L152xx that has an AES128 (CBC) encryption peripheral. However, to initialize random IV, I am looking for a good scheme for creating a cryptographically secure sequence of random numbers. I am now using a simple LCRG (linear congruent generator) as the site owner, but this is weak.

I'm new to implementing encryption on an embedded platform, so I'm wondering what is the common practice for creating cryptographic PRNG? Or what is a good strategy for choosing a key and IV?

Most StackOverflow responses for cryptographic PRNG refer to a third-party library that is not available on this platform. However, if it's worth a try, I can try porting it. Links and pointers to resources will also be useful!

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

Answer 1

You will probably need to define “Cryptographically Secure” or your application is slightly better. If it were for playing on a mobile phone, you could use the accelerometer as a source of randomness. If you are trying to sign x.509 certificates, you might consider some connected hardware that measures radioactive decay.

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

• The current 32-bit clock value that ticks every nanosecond (A period of about 4 seconds - probably "Random" is enough depending on how often you need seeds). You need to make sure that you do not get this value in a deterministic way. If it is based on user input during capture, then this is probably OK.
• Avalanche noise generator inserted into Schmitt trigger input.
• Exclusive OR of all axes of the accelerometer (maybe it’s not good if the thing is still sitting, unless it accepts vibration in its normal application). If this is for a radio that carries around, then this is probably good.
• The value of a large chunk of uninitialized memory (you probably want to hash it because large sections of uninitialized memory can contain the same values ​​from power on to power on). Also, if your device doesn’t turn off completely, it’s probably not very good.
• Some combination of one or more of the above (Exclusive OR is probably the easiest way to combine two of the above outputs)
• Comedy variant: CCD camera pointed to a lava lamp

For any of the above methods, you may need some kind of de-bias algorithm applied to them. The easiest one is to consider your input 2 bits at a time. If two bits are equal, cancel them. 0b10 becomes 1 and 0b01 becomes 0. This ensures that you get more or less the same number 1 and 0 in the final final value.

Finally, if this is for something serious, you should neglect all the tips above and DO NOT MISS YOUR OWN CRYPTO. Find the API for your platform that has already been tested and uses it. Testing an algorithm for randomness is very difficult to do.

Perhaps consider the F-2 series of the STM32 core , which apparently contains hardware RNG

Answer 2

Pete Brahman's answer suggests what a good answer this question should: non-biasing and combining weak sources of entropy. I would hesitate a bit to use uninitialized memory in this process; I can think of scenarios where a system based on the assumption that uninitialized memory was not previously used by an attacker may be compromised. Other than that, I cannot but agree.

In the interest of saving time on the invention of a possibly already invented wheel, I would like to briefly consider cryptlib providing you have not done so; "Highly portable cryptlib means it is also used in a variety of custom embedded system environments, including AMX, ChorusOS, eCos, FreeRTOS / OpenRTOS, uITRON, MQX, PalmOS, RTEMS, ThreadX, T-Kernel, uC / OS II, VDK, VxWorks and XMK. " This library probably does most of the work for you; Assuming it is possible to use cryptlib, you may only need to pass it random information (from several sources): "The random data collection operation is controlled using cryptAddRandom, which can be used to enter your own random information into the internal randomness pool or inform cryptlib about the survey systems for random information. "

Answer 3

I know this is a pretty old question, but since no one has mentioned the cryptographically secure PRNG yet, I thought I wanted to call back. A “cryptographically secure” IV and keys must be generated using cryptographic PRNG, for example. HMAC_DRBG or CTR_DRBG . The former is based on HMAC , the latter is based on AES in CTR . These two PRNGs are available in PolarSSL, which also runs on FreeRTOS . Take care NOT to use DUAL_EC_DRBG, it is backdoored by NSA and will never be used again.

Most importantly, you need an entropy source for the seeds of these PRNGs. Unfortunately, this is the hard part of embedded devices. You can find some ideas on this blog , for example. with ADC output.

In particular, on IV, another important criterion is that it should be unpredictable. That is, there should not be a systematic way for an attacker to predict the IV of the next ciphertext, given the current ciphertext. This is to avoid a BEAST-like attack on TLS 1.0 .

Finally, for these kinds of questions, you will be more likely to get excellent answers at crypto.stackexchange.com .