colorful lottery balls

Random numbers -- really, truly random numbers -- play a very important role in security. Everything from key generation, nonces, shuffling, secure protocols, and many forms of challenge-response rely on unpredictable numbers.

There are many ways that things go wrong. Firmware engineers will often use the rand() function from the C standard library (often without seeding), either because they don't know any better, or because they feel they don't have a good alternative (no excuse!) Or they'll obtain a "good" random number, but then introduce a bias when converting that larger random number into a smaller range.

There are myriad ways things can go wrong. That's one of the reasons we devote an entire section to the topic in Barr Group's Embedded Security Boot Camp. One of the things I discuss in the course is how things can go wrong with "random" numbers. One of the examples is the 2013 Arizona Lottery; a "glitch" prevented the digits 8 and 9 from being drawn in certain positions.

Well, guess what? It's now 2017, and the Arizona Lottery is back, in an attempt to out-do itself, apparently now "technical difficulties" with the lottery's random number generator have resulted in the same winning numbers being generated repeatedly. Ooops. Quoting the article: "the machine generated the same winning numbers in multiple drawings for three different games."

At least this problem made itself very obvious. Often the failures and problems with random number generators in security systems are subtler and go undetected for longer periods of time.

Does your embedded product use random numbers as part of its security framework? If so, where do they come from? Is there a bias, even a slight one? (Are you sure?) If you suspect a bias, how are you removing it? Would your firmware detect a scenario where there is a failure in your random number generator?

Security is hard. Random numbers are one of the easier things to get right, but I've encountered a multitude of different problems while performing security audits / firmware reviews. And I don't have space here to get into the nuances of hardware-generated random numbers vs. cryptographically secure random number generators, whitening and entropy extraction, etc.